tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: 8f44df154de79a61b0e86734f51737b8cccf8dfe [87/87] crypto: ecdh - make
ecdh_shared_secret unique
config: s390-allyesconfig (attached as .config)
compiler
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: d56d72c6a0612be14ccb455c92886d2cb102c2ab [84/87] KEYS: Use skcipher for
big keys
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-
On Fri, Jun 24, 2016 at 08:25:02AM -0700, Tadeusz Struk wrote:
> Yes, but now mpi_get_buffer() calls mpi_read_buffer() and it is also
> used by security/keys/dh.c
It appears to be using mpi_read_buffer gratuitously. It should
simply use mpi_get_buffer.
Thanks,
--
Email: Herbert Xu
Home Page: h
On Fri, Jun 24, 2016 at 01:06:02PM +0100, David Howells wrote:
>
> The problem is that if I'm to produce consistency with, say, the TPM
> interface, then I have to deal in wrapped/padded data - leastways as far as I
> can tell from reading the docs.
So the TPM device is accessed through the same
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 8f44df154de79a61b0e86734f51737b8cccf8dfe
commit: 3c4b23901a0c766879dff680cd6bdab47bcdbbd2 [79/87] crypto: ecdh - Add
ECDH software support
config: s390-allyesconfig (attached as .config)
compiler: s39
On 06/24/2016 06:31 AM, Herbert Xu wrote:
> On Wed, Jun 22, 2016 at 05:27:02PM -0700, Florian Fainelli wrote:
>> The Broadcom BCM5301x SoCs (Northstar) utilize the same random number
>> generator peripheral as Northstar Plus and BCM2835, but just like the
>> NSP SoC, we need to enable the interrupt
On 06/24/2016 11:50 AM, Nishanth Menon wrote:
> pm_runtime_get_sync does return a error value that must be checked for
> error conditions, else, due to various reasons, the device maynot be
> enabled and the system will crash due to lack of clock to the hardware
> module.
>
Oh crap! Apologies, p
[#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at
[#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at
On 06/24/2016 11:35 AM, Suman Anna wrote:
[...]
>> diff --git a/drivers/char/hw_random/omap-rng.c
>> b/drivers/char/hw_random/omap-rng.c
>> index 8a1432e8bb80..f30a1870cb64 100644
>> --- a/drivers/char/hw_random/omap-rng.c
>> +++ b/drivers/char/hw_random/omap-rng.c
>> @@ -384,7 +384,11 @@ static i
> module.
>
> Before:
> 12.562784] [] *pgd=fe193835
> 12.562792] Internal error: : 1406 [#1] SMP ARM
> [...]
> 12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624
> #2
> 12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
> 12.5628
[#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at
On 06/24/2016 07:28 AM, Herbert Xu wrote:
> Didn't we add mpi_read_buffer specifically for akcipher before
> we switched over to SGs? If nobody is using it we should just
> delete it.
Yes, but now mpi_get_buffer() calls mpi_read_buffer() and it is also
used by security/keys/dh.c
Thanks,
--
TS
--
T
On Thu, Jun 23, 2016 at 08:25:05AM -0700, Tadeusz Struk wrote:
>
> The reason why mpi_write_to_sgl() strips the leading zeros is only
> because we said that it needs to work in the same way as the
> mpi_read_buffer(), which does remove it for whatever reason.
> So should we now change the mpi_read
Add Giovanni and Salvatore who will take over the qat maintenance.
Signed-off-by: Tadeusz Struk
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f4a9c13..5d813a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9292,7 +9292,8 @@
On Wed, Jun 22, 2016 at 05:27:02PM -0700, Florian Fainelli wrote:
> The Broadcom BCM5301x SoCs (Northstar) utilize the same random number
> generator peripheral as Northstar Plus and BCM2835, but just like the
> NSP SoC, we need to enable the interrupt.
>
> Signed-off-by: Florian Fainelli
Patch
On Wed, Jun 22, 2016 at 07:26:06PM +0200, Stephan Mueller wrote:
> Hi John, Herbert,
>
> Changes v2: use ktime_get_ns instead of ktime_get_raw_ns
>
> The testing was re-performed and indicate no difference to the previous
> testing.
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http
On Wed, Jun 22, 2016 at 04:23:34PM +0300, Tero Kristo wrote:
> Calling runtime PM API for every block causes serious performance hit to
> crypto operations that are done on a long buffer. As crypto is performed
> on a page boundary, encrypting large buffers can cause a series of crypto
> operations
Am Freitag, 24. Juni 2016, 07:44:49 schrieb Gary R Hook:
Hi Gary,
> On 06/24/2016 07:01 AM, Stephan Mueller wrote:
> > Am Freitag, 24. Juni 2016, 17:24:02 schrieb Harsh Jain:
> >
> > Hi Harsh,
> >
> >> 379 * The memory structure for cipher operation has the
> >> following
> >> 380
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Friday, June 24, 2016 7:45 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org; Wu, Fengguang
> ; linux-blueto...@vger.kernel.org
> Subject: Re: [cryptodev:master 79/79] (.text+0x330de0): mu
* Convert both smp and selftest to new crypto kpp API
* Remove module ecc as not more required
* Add ecdh_helper functions for wrapping kpp async calls
Signed-off-by: Salvatore Benedetto
---
Patch is based on
http://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
Tested wi
On 06/24/2016 07:01 AM, Stephan Mueller wrote:
Am Freitag, 24. Juni 2016, 17:24:02 schrieb Harsh Jain:
Hi Harsh,
379 * The memory structure for cipher operation has the following
380 * structure:
381 * AEAD encryption input: assoc data || plaintext
382
Herbert Xu wrote:
> IOW exporting the raw RSA might make sense because the key may
> not be visible to user-space, or that the RSA might be implemented
> in hardware offload, but there is no sane reason to export pkcs1pad.
The problem is that if I'm to produce consistency with, say, the TPM
inte
Yes, I will share the patch.
regards
Harsh Jain
On Fri, Jun 24, 2016 at 5:31 PM, Stephan Mueller wrote:
> Am Freitag, 24. Juni 2016, 17:24:02 schrieb Harsh Jain:
>
> Hi Harsh,
>
>
>> 379 * The memory structure for cipher operation has the following
>> 380 * structure:
>> 381
Am Freitag, 24. Juni 2016, 17:24:02 schrieb Harsh Jain:
Hi Harsh,
> 379 * The memory structure for cipher operation has the following
> 380 * structure:
> 381 * AEAD encryption input: assoc data || plaintext
> 382 * AEAD encryption output: ciphernte
Hi Stephan,
It seems now AEAD encryption operation also returns AAD to user space
in output buffer. Following comment in aead_recvmsg() needs updation:
/*
373 * AEAD memory structure: For encryption, the tag is appended to the
374 * ciphertext which implies that the memory alloc
On Wed, Jun 22, 2016 at 04:23:39PM +0300, Tero Kristo wrote:
> The statesize is used to determine the maximum size for saved ahash
> context. In some cases, this can be much larger than what is currently
> allocated for it, for example omap-sham driver uses a buffer size of
> PAGE_SIZE. Increase th
On Wed, Jun 22, 2016 at 04:23:38PM +0300, Tero Kristo wrote:
> Some of the call paths of OMAP SHA driver can avoid executing the next
> step of the crypto queue under tasklet; instead, execute the next step
> directly via function call. This avoids a costly round-trip via the
> scheduler giving a s
Mat Martineau wrote:
>
>> + if (strcmp(encoding, "pkcs1") == 0) {
>> + /* The data wangled by the RSA algorithm is typically padded
>> + * and encoded in some manner, such as EMSA-PKCS1-1_5 [RFC3447
>> + * sec 8.2].
>> + */
>> + if
On Fri, Jun 24, 2016 at 11:23:06AM +0200, Stephan Mueller wrote:
>
> Patch 2 introduces the bug.
>
> Note, with patch 2, there is also a compile warning with crypto/dh.c.
Oh I see. It's a conflict with the kpp stuff that didn't exist
when I wrote this.
Let me respin the patches on top of kpp.
On Fri, Jun 24, 2016 at 09:37:28AM +0100, Giovanni Cabiddu wrote:
>
> I'll remove scomp and refit the software algos to plug into acomp
> directly.
> Would it be admissible if software algos implementations will vmalloc
> the source and the destination buffers for linearizing the scatter gather
> l
Am Freitag, 24. Juni 2016, 16:41:47 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jun 24, 2016 at 09:27:12AM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 22. Juni 2016, 18:14:32 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > Something breaks with this patch set in public_key_verify_signature
> >
Hi Herbert,
After merging the crypto tree, today's linux-next build (powerpc
allyesconfig) failed like this:
net/built-in.o: In function `.ecdh_shared_secret':
(.text+0x4ad8d0): multiple definition of `.ecdh_shared_secret'
crypto/built-in.o:(.text+0x113f0): first defined here
net/built-in.o:(.opd
Am Freitag, 24. Juni 2016, 16:41:47 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jun 24, 2016 at 09:27:12AM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 22. Juni 2016, 18:14:32 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > Something breaks with this patch set in public_key_verify_signature
> >
On Fri, Jun 24, 2016 at 09:27:12AM +0200, Stephan Mueller wrote:
> Am Mittwoch, 22. Juni 2016, 18:14:32 schrieb Herbert Xu:
>
> Hi Herbert,
>
> Something breaks with this patch set in public_key_verify_signature
>
> I get tons of these:
>
> [1.838720] PKCS#7 signature not signed with a trus
On Fri, Jun 24, 2016 at 10:29:34AM +0200, Steffen Klassert wrote:
>
> Thanks for the patches!
> I've tested them today and observed no problems with it,
> so looks good :)
Thanks for testing!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au
On Thu, Jun 23, 2016 at 06:50:34PM +0800, Herbert Xu wrote:
> No that's not the problem. The problem is that you can't kmalloc
> 64K of memory. kmalloc requires physically contiguous memory and
> you cannot rely on having 64K of contiguous memory.
It is clear now. Thanks.
> > > This totally brea
On Tue, Jun 21, 2016 at 04:53:21PM +0800, Herbert Xu wrote:
> Hi:
>
> I finally got around to working on this. I quickly gave up on the
> notion of hijacking the queued requests as we may end up overwhelming
> our caller.
>
> So the solution is the obvious one of using cryptd as long as there
>
Am Mittwoch, 22. Juni 2016, 18:14:32 schrieb Herbert Xu:
Hi Herbert,
Something breaks with this patch set in public_key_verify_signature
I get tons of these:
[1.838720] PKCS#7 signature not signed with a trusted key
Furthermore, my CAVS testing with public_key_verify_signature always EINV
39 matches
Mail list logo
