From: Tudor Ambarus
commit 394a9e044702 ("crypto: cfb - add missing 'chunksize' property")
adds a test vector where the input length is smaller than the IV length
(the second test vector). This revealed a NULL pointer dereference in
the atmel-aes driver, that is caused by passing an incorrect off
The patch brings support of several BLAKE2 variants (2b with various
digest lengths). The in-tree user will be btrfs (for checksumming),
we're going to use the BLAKE2b-256 variant.
The code is reference implementation taken from the official sources and
modified only in terms of kernel coding styl
I'm facing the same problem on one of my VPN gateways.
I updated the affected system from Debian Stretch to Buster.
Therefore the kernel was updated from 4.9.x to 4.19.x
The supplied patch uses some symbols / functions that were introduced
with 4.19 (like crypto_sync_skcipher_clear_flags()) so s
On Fri, 4 Oct 2019 at 12:21, Florian Bezdeka wrote:
>
> I'm facing the same problem on one of my VPN gateways.
>
> I updated the affected system from Debian Stretch to Buster.
> Therefore the kernel was updated from 4.9.x to 4.19.x
>
> The supplied patch uses some symbols / functions that were int
Hi Ard,
On Wed, Oct 02, 2019 at 04:16:53PM +0200, Ard Biesheuvel wrote:
> This is a followup to RFC 'crypto: wireguard with crypto API library
> interface'
> [0]. Since no objections were raised to my approach, I've proceeded to fix up
> some minor issues, and incorporate [most of] the missing MI
On Wed, Oct 02, 2019 at 04:16:54PM +0200, Ard Biesheuvel wrote:
>
> chacha_permute(x, nrounds);
Interested in porting my single-statement unrolled implementation from
Zinc to this? I did see performance improvements on various platforms.
> From: Mimi Zohar
> Sent: Thursday, October 3, 2019 2:54 PM
> To: Jarkko Sakkinen ; Safford, David (GE
> Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
>
> [Cc'ing David Safford]
>
> On Thu, 2019-10-03 at 20:58 +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 03, 2019 at 09
Op 04-10-2019 om 08:16 schreef Ard Biesheuvel:
On Thu, 3 Oct 2019 at 23:26, Gert Robben wrote:
Op 03-10-2019 om 15:39 schreef Ard Biesheuvel:
Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated
the generic CBC template wrapper from a blkcipher to a skcipher algo,
to get away
On Wed, Oct 02, 2019 at 04:16:55PM +0200, Ard Biesheuvel wrote:
> Wire the existing x86 SIMD ChaCha code into the new ChaCha library
> interface.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/x86/crypto/chacha_glue.c | 36
> crypto/Kconfig| 1 +
> include/c
On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel wrote:
> >
> ...
> >
> > In the future, I would like to extend these interfaces to use static calls,
> > so that the accelerated implementations can be [un]plugged at runtime. For
> > the
On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> This integrates the accelerated MIPS 32r2 implementation of ChaCha
> into both the API and library interfaces of the kernel crypto stack.
>
> The significance of this is that, in addition to becoming available
> as an accelerated li
On Wed, Oct 02, 2019 at 04:17:03PM +0200, Ard Biesheuvel wrote:
> This integrates the accelerated MIPS 32r2 implementation of ChaCha
> into both the API and library interfaces of the kernel crypto stack.
>
> The significance of this is that, in addition to becoming available
> as an accelerated li
On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
>
> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> > On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
> > wrote:
> > >
> > ...
> > >
> > > In the future, I would like to extend these interfaces to use static
> > > calls,
> > >
On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel wrote:
> Expose the accelerated NEON ChaCha routine directly as a symbol
> export so that users of the ChaCha library can use it directly.
Eric had some nice code for ChaCha for certain ARM cores that lived in
Zinc as chacha20-unrolled-arm.S. This cod
On Fri, 4 Oct 2019 at 15:36, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:16:55PM +0200, Ard Biesheuvel wrote:
> > Wire the existing x86 SIMD ChaCha code into the new ChaCha library
> > interface.
> >
> > Signed-off-by: Ard Biesheuvel
> > ---
> > arch/x86/crypto/chacha_glue.c | 36 ++
On Wed, Oct 02, 2019 at 04:17:07PM +0200, Ard Biesheuvel wrote:
>- replace .c #includes with Kconfig based object selection
Cool!
> +config CRYPTO_ARCH_HAVE_LIB_CURVE25519
> + tristate
> +
> +config CRYPTO_ARCH_HAVE_LIB_CURVE25519_BASE
> + bool
> +
> +config CRYPTO_LIB_CURVE25519
On Wed, Oct 02, 2019 at 04:17:11PM +0200, Ard Biesheuvel wrote:
> +bool curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
> + const u8 scalar[CURVE25519_KEY_SIZE],
> + const u8 point[CURVE25519_KEY_SIZE])
> +{
> + if (!have_neon || !crypto_simd_usable())
> +
On Fri, 4 Oct 2019 at 15:57, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:07PM +0200, Ard Biesheuvel wrote:
> >- replace .c #includes with Kconfig based object selection
>
> Cool!
>
> > +config CRYPTO_ARCH_HAVE_LIB_CURVE25519
> > + tristate
> > +
> > +config CRYPTO_ARCH_
On Wed, Oct 02, 2019 at 04:17:13PM +0200, Ard Biesheuvel wrote:
> Reimplement the library routines to perform chacha20poly1305 en/decryption
> on scatterlists, without [ab]using the [deprecated] blkcipher interface,
> which is rather heavyweight and does things we don't really need.
>
> Instead, w
On Fri, 4 Oct 2019 at 16:03, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:13PM +0200, Ard Biesheuvel wrote:
> > Reimplement the library routines to perform chacha20poly1305 en/decryption
> > on scatterlists, without [ab]using the [deprecated] blkcipher interface,
> > which is rather
On Fri, 4 Oct 2019 at 16:01, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:17:11PM +0200, Ard Biesheuvel wrote:
> > +bool curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
> > + const u8 scalar[CURVE25519_KEY_SIZE],
> > + const u8 point[CURVE25519_KEY_SIZE])
On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel wrote:
> This is a followup to RFC 'crypto: wireguard with crypto API library
> interface'
> [0]. Since no objections were raised to my approach, I've proceeded to fix up
> some minor issues, and incorporate [most of] the missing MIPS code.
Could you
On Fri, 4 Oct 2019 at 15:53, Jason A. Donenfeld wrote:
>
> On Wed, Oct 2, 2019 at 4:17 PM Ard Biesheuvel
> wrote:
> > Expose the accelerated NEON ChaCha routine directly as a symbol
> > export so that users of the ChaCha library can use it directly.
>
> Eric had some nice code for ChaCha for cer
On Thu, Sep 12, 2019 at 03:30:22PM +0200, Laurent Vivier wrote:
>
> @@ -496,19 +510,24 @@ int hwrng_register(struct hwrng *rng)
> goto out_unlock;
> }
>
> - if (old_rng && !rng->init) {
> + new_rng = rng;
> + kref_get(&new_rng->ref);
> +out_unlock:
> +
On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel wrote:
> > Did these changes make it into the existing tree?
>
> I'd like to keep Eric's code, but if it is really that much faster, we
> might drop it in arch/arm/lib so it supersedes the builtin code that
> /dev/random uses as well.
That was the ide
On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel wrote:
> How is it relevant whether the boot CPU is A5 or A7? These are bL
> little cores that only implement NEON for feature parity with their bl
> big counterparts, but CPU intensive tasks are scheduled on big cores,
> where NEON performance is much
On Fri, 4 Oct 2019 at 15:46, Jason A. Donenfeld wrote:
>
> On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> > This integrates the accelerated MIPS 32r2 implementation of ChaCha
> > into both the API and library interfaces of the kernel crypto stack.
> >
> > The significance of thi
On Fri, 4 Oct 2019 at 16:38, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 15:46, Jason A. Donenfeld wrote:
> >
> > On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> > > This integrates the accelerated MIPS 32r2 implementation of ChaCha
> > > into both the API and library interf
> On Oct 4, 2019, at 6:42 AM, Jason A. Donenfeld wrote:
>
> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>>
>> ...
>>>
>>> In the future, I would like to extend these interfaces to use static calls,
>>> so that
> On Oct 4, 2019, at 6:52 AM, Ard Biesheuvel wrote:
>
> On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
>>
>>> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel
>>> wrote:
>>> ...
In the future, I would
On Fri, Oct 4, 2019 at 4:53 PM Andy Lutomirski wrote:
> I think it might be better to allow two different modules to export the same
> symbol but only allow one of them to be loaded. Or use static calls.
Static calls perform well and are well understood. This would be my preference.
On Fri, 4 Oct 2019 at 16:53, Andy Lutomirski wrote:
>
>
>
> > On Oct 4, 2019, at 6:52 AM, Ard Biesheuvel
> > wrote:
> >
> > On Fri, 4 Oct 2019 at 15:42, Jason A. Donenfeld wrote:
> >>
> >>> On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
> >>> On Wed, 2 Oct 2019 at 16:17, Ard B
On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel wrote:
> The round count is passed via the fifth function parameter, so it is
> already on the stack. Reloading it for every block doesn't sound like
> a huge deal to me.
Please benchmark it to indicate that, if it really isn't a big deal. I
recall fi
On Fri, 4 Oct 2019 at 16:55, Jason A. Donenfeld wrote:
>
> On Fri, Oct 4, 2019 at 4:53 PM Andy Lutomirski wrote:
> > I think it might be better to allow two different modules to export the
> > same symbol but only allow one of them to be loaded. Or use static calls.
>
> Static calls perform well
On Fri, 4 Oct 2019 at 16:59, Jason A. Donenfeld wrote:
>
> On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
> wrote:
> > The round count is passed via the fifth function parameter, so it is
> > already on the stack. Reloading it for every block doesn't sound like
> > a huge deal to me.
>
> Please b
Hi Jason,
Quoting "Jason A. Donenfeld" :
On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
wrote:
The round count is passed via the fifth function parameter, so it is
already on the stack. Reloading it for every block doesn't sound like
a huge deal to me.
Please benchmark it to indicate that,
On Fri, 4 Oct 2019 at 17:15, René van Dorst wrote:
>
> Hi Jason,
>
> Quoting "Jason A. Donenfeld" :
>
> > On Fri, Oct 4, 2019 at 4:44 PM Ard Biesheuvel
> > wrote:
> >> The round count is passed via the fifth function parameter, so it is
> >> already on the stack. Reloading it for every block does
On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel wrote:
>
> How is it relevant whether the boot CPU is A5 or A7? These are bL
> little cores that only implement NEON for feature parity with their bl
> big counterparts, but CPU intensive tasks are scheduled on big cores,
> where NEON performance is mu
On Mon, Sep 09, 2019 at 01:10:29PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the CRC32 "hash" algorithm
>
> Signed-off-by: Pascal van Leeuwen
> ---
> drivers/crypto/inside-secure/safexcel.c | 1 +
> drivers/crypto/inside-secure/safexcel.h | 2 +
> drivers/crypt
On Mon, Sep 09, 2019 at 01:13:05PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the (AES) CBCMAC family of authentication
> algorithms: AES-CBCMAC, AES-XCBCMAC and AES-MAC
> It has been verified with a Xilinx PCIE FPGA board as well as the Marvell
> Armada A8K based Macchiatobi
On Tue, Sep 10, 2019 at 06:04:14AM +, Christophe Leroy wrote:
> When VMAP_STACK is selected, stack cannot be DMA-mapped.
> Therefore, the hash result has to be DMA-mapped in the request
> context and copied into areq->result at completion.
>
> Signed-off-by: Christophe Leroy
> ---
> drivers/
On Wed, Sep 11, 2019 at 12:18:58AM +0100, Ard Biesheuvel wrote:
> This series reimplements gcm(aes) for arm64 systems that support the
> AES and 64x64->128 PMULL/PMULL2 instructions. Patch #1 adds a test
> case and patch #2 updates the driver.
>
> Ard Biesheuvel (2):
> crypto: testmgr - add anot
On Thu, Sep 12, 2019 at 12:01:47PM +0300, Tomer Maimon wrote:
> This patch set adds Random Number Generator (RNG) support
> for the Nuvoton NPCM Baseboard Management Controller (BMC).
>
> The RNG driver we use power consumption when the RNG
> is not required.
>
> The NPCM RNG driver tested on N
On Fri, Sep 13, 2019 at 11:10:35AM +0200, Pascal van Leeuwen wrote:
> Extend driver support with ecb(sm4), cbc(sm4), ofb(sm4), cfb(sm4) and
> rfc3686(ctr(sm4)) skcipher algorithms.
> Also add ofb(sm4), cfb(sm4) and rfc3686(ctr(sm4)) testvectors to testmgr.
> The patchset has been tested with the ei
On Fri, Sep 13, 2019 at 05:20:35PM +0200, Pascal van Leeuwen wrote:
> Extend driver support with sm3 and hmac(sm3) ahash support.
> Also add GM/T 0042-2015 hmac(sm3) testvectors to the testmgr.
> The patchset has been tested with the eip197c_iewxkbc configuration
> on the Xilinx VCU118 development
On Fri, Sep 13, 2019 at 07:36:18PM +0100, Ard Biesheuvel wrote:
> The next version of Clang will start policing compiler command line
> options, and will reject combinations of -march and -mfpu that it
> thinks are incompatible.
>
> This results in errors like
>
> clang-10: warning: ignoring ex
On 04/10/2019 16:26, Herbert Xu wrote:
> On Thu, Sep 12, 2019 at 03:30:22PM +0200, Laurent Vivier wrote:
>>
>> @@ -496,19 +510,24 @@ int hwrng_register(struct hwrng *rng)
>> goto out_unlock;
>> }
>>
>> -if (old_rng && !rng->init) {
>> +new_rng = rng;
>> +kref
On Fri, Sep 13, 2019 at 10:04:43PM +0200, Pascal van Leeuwen wrote:
> This patchset adds the remaining authencs with DES or 3DES currently
> supported with vectors by testmgr.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> Xilinx VCU118 development boardi as well
On Fri, Sep 13, 2019 at 08:56:46PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for all flavours of sha3-xxx and hmac(sha3-xxx)
> ahash algorithms.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> Xilinx VCU118 development board, including the testm
On Fri, Sep 13, 2019 at 08:44:50PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the authenc(hmac(sha1),cbc(sm4)),
> authenc(hmac(sm3),cbc(sm4)), authenc(hmac(sha1),rfc3686(ctr(sm4))),
> and authenc(hmac(sm3),rfc3686(ctr(sm4))) aead ciphersuites.
> These are necessary to support IP
On Fri, 4 Oct 2019 at 17:24, Arnd Bergmann wrote:
>
> On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel
> wrote:
> >
> > How is it relevant whether the boot CPU is A5 or A7? These are bL
> > little cores that only implement NEON for feature parity with their bl
> > big counterparts, but CPU intensiv
On Fri, Oct 4, 2019 at 5:36 PM Ard Biesheuvel wrote:
> > Just checking for Cortex-A7 being the boot CPU is probably
> > sufficient, that takes care of the common case of all the
> > A7-only embedded chips that people definitely are going to care
> > about for a long time.
> >
>
> But do you agree
On Tue, Sep 17, 2019 at 06:36:50AM +, Nagadheeraj Rottela wrote:
> Self test failures are due to wrong output IV. This patch fixes this
> issue by copying back output IV into skcipher request.
>
> Signed-off-by: Nagadheeraj Rottela
> Reviewed-by: Srikanth Jampala
> ---
> drivers/crypto/cavi
On Tue, Sep 17, 2019 at 11:55:17AM +0200, Pascal van Leeuwen wrote:
> This patchset fixes some issues with the TRC RAM probing that caused
> instability (random failures) on the Macchiatobin board and incorrect
> configuration of the TRC for some other corner case RAM configuration.
>
> The patchs
On Tue, Sep 17, 2019 at 12:07:58PM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the rfc4106(gcm(aes)), rfc4543(gcm(aes))
> and rfc4309(ccm(aes)) ciphersuites intended for IPsec ESP acceleration.
>
> The patchset has been tested with the eip197c_iewxkbc configuration on the
> X
On Mon, Sep 16, 2019 at 06:42:06AM +, Nagadheeraj Rottela wrote:
> Check if device supports assoclen to solve hung task timeout error when
> extra tests are enabled. Return -EINVAL if assoclen is not supported.
> Check authsize to return -EINVAL if authentication tag size is invalid.
> Change b
On Wed, Sep 18, 2019 at 08:42:38AM +0200, Pascal van Leeuwen wrote:
> This patchset adds support for the eip197f_iewc configuration that is
> currently being taped-out by a customer. It adds support for the 256 bit
> internal buswidth used by larger EIP197's as well as support for having
> less rin
On Wed, Sep 18, 2019 at 09:39:34AM +, Nagadheeraj Rottela wrote:
> Add support to get microcode information in VF from PF via mailbox
> message.
>
> Signed-off-by: Nagadheeraj Rottela
> Reviewed-by: Srikanth Jampala
> ---
> drivers/crypto/cavium/nitrox/nitrox_dev.h | 15 +++
> d
On Wed, Sep 18, 2019 at 12:41:26PM +0200, Pascal van Leeuwen wrote:
> This patch adds support for the EIP196, which is an EIP197 derivative
> that has no classification hardware and a simplified record cache.
>
> The patch has been tested with the eip196b-ie and eip197c-iewxkbc
> configurations on
Alexander E. Patrakov wrote:
> One should not say "ec can be NULL" and then dereference it.
> One cannot talk about the return value if the function returns void.
>
> Signed-off-by: Alexander E. Patrakov
> ---
> crypto/jitterentropy.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
On Wed, Sep 18, 2019 at 09:44:06AM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 18 Sep 2019 09:34:11 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elf
On Fri, Oct 04, 2019 at 04:29:57PM +0200, Jason A. Donenfeld wrote:
> On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel
> wrote:
> > How is it relevant whether the boot CPU is A5 or A7? These are bL
> > little cores that only implement NEON for feature parity with their bl
> > big counterparts, but C
On Wed, Sep 18, 2019 at 11:25:55PM +0200, Pascal van Leeuwen wrote:
> Extend driver support with chacha20, rfc7539(chacha20,poly1305) and
> rfc7539esp(chacha20,poly1305) ciphers.
> The patchset has been tested with the eip197c_iesb and eip197c_iewxkbc
> configurations on the Xilinx VCU118 developme
On Wed, Sep 18, 2019 at 09:19:18AM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 18 Sep 2019 09:09:22 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elf
On Thu, Sep 19, 2019 at 04:09:06PM +0200, Arnd Bergmann wrote:
> To avoid missing arm64 specific warnings that get introduced
> in this driver, allow compile-testing on all 64-bit architectures.
>
> The only actual arm64 specific code in this driver is an open-
> coded 128 bit MMIO write. On non-a
On Thu, Sep 19, 2019 at 06:33:02PM -0300, Eneas U de Queiroz wrote:
> Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
> the qce driver, since they are all hardware accelerated, accessible
> through a kernel driver only, and not available directly to userspace.
>
> Signed-off-
On Thu, Sep 19, 2019 at 11:04:48AM -0500, Navid Emamdoost wrote:
> Release all allocated memory if sha type is invalid:
> In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
> hmac_buf should be released.
>
> v2: fix the goto.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/cryp
On Fri, Sep 20, 2019 at 06:35:19AM +, Phani Kiran Hemadri wrote:
> This patch fixes assigning UCD block number of Asymmetric crypto
> firmware to AE cores of CNN55XX device.
>
> Fixes: a7268c4d4205 ("crypto: cavium/nitrox - Add support for loading
> asymmetric crypto firmware")
> Signed-off-b
On Thu, Sep 19, 2019 at 10:04:28PM +0200, Christophe JAILLET wrote:
> Use '__skb_put_data()' instead of rewritting it.
> This improves readability.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/crypto/chelsio/chtls/chtls_io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch
On Thu, Sep 26, 2019 at 03:26:29PM +0300, Iuliana Prodan wrote:
> The mapped_{src,dst}_nents _returned_ from the dma_map_sg
> call (which could be less than src/dst_nents) have to be
> used to generate the job descriptors.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes since v1:
> - updated, w
On Tue, Sep 24, 2019 at 10:08:30AM +0200, Corentin Labbe wrote:
> Hello
>
> This serie enables power management in the sun4i-ss driver.
>
> Regards
>
> Changes since v2 (
> https://lore.kernel.org/linux-arm-kernel/20190919051035.4111-2-clabbe.montj...@gmail.com/T/
> ):
> - depends on PM
> - fu
On Sat, Sep 14, 2019 at 02:02:53PM -0700, Tony Lindgren wrote:
> Hi all,
>
> Here are fixes and improvments for omap3-rom-rng that's been broken for
> a while.
>
> The first four patches get it working, and then the last two patches add
> support for runtime PM.
>
> I did not add Sebastian's ack
On Wed, Oct 02, 2019 at 12:35:06PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, Oct 01, 2019 at 08:41:32PM +0200, Corentin Labbe wrote:
> > + /* CTS and recent CE (H6) need length in bytes, in word otherwise */
> > + if (ce->variant->model == CE_v2)
> > + cet->t_dlen = areq->cryptle
On Wed, Oct 02, 2019 at 07:54:58AM +0200, Maxime Ripard wrote:
> On Tue, Oct 01, 2019 at 08:41:33PM +0200, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > Crypto Engine cryptographic accelerator driver.
> >
> > Signed-off-by: Corentin Labbe
> > ---
> >
when libkcapi test is executed using HW accelerator, cipher operation
return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int,
libkcapi receive 429467222 even though it expect -ve value.
Hence its required to cast resultlen to int so that proper
error is returned to libkcapi.
AEA
On Thu, Oct 03, 2019 at 06:08:11PM -0400, Mimi Zohar wrote:
> > At the time when trusted keys was introduced I'd say that it was a wrong
> > design decision and badly implemented code. But you are right in that as
> > far that code is considered it would unfair to speak of a regression.
> >
> > as
On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> I think the principle of using multiple RNG sources for strong keys is
> a sound one, so could I propose a compromise: We have a tpm subsystem
> random number generator that, when asked for random bytes first
> extracts bytes fro
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > I think the principle of using multiple RNG sources for strong keys
> > is a sound one, so could I propose a compromise: We have a tpm
> > subsystem random number genera
On Fri, Oct 04, 2019 at 01:26:58PM +, Safford, David (GE Global Research,
US) wrote:
> As the original author of trusted keys, let me make a few comments.
> First, trusted keys were specifically implemented and *documented* to
> use the TPM to both generate and seal keys. Its kernel documentat
> > There are many good reasons for wanting the keys to be based on the
> > TPM generator. As the source for the kernel random number generator
> > itself says, some systems lack good randomness at startup, and systems
> > should preserve and reload the pool across shutdown and startup.
> > There
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> I think the principle of using multiple RNG sources for strong keys
> is a sound one, so could I propose a compromise: We have a
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
> On Fri Oct 04 19, James Bottomley wrote:
> > On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > > > I think the principle of using multiple RNG sources for
On Fri, Oct 04, 2019 at 11:35:29AM +0530, Sumit Garg wrote:
> Hi Jarkko,
>
> On Wed, 25 Sep 2019 at 06:41, Jarkko Sakkinen
> wrote:
> >
> > On Wed, Sep 18, 2019 at 11:53:08AM +0530, Sumit Garg wrote:
> > > No worries :). I will send next version of patch-set.
> > >
> > > FYI, I will be travelling
In crypto_report, a new skb is created via nlmsg_new(). This skb should
be released if crypto_report_alg() fails.
Fixes: a38f7907b926 ("crypto: Add userspace configuration API")
Signed-off-by: Navid Emamdoost
---
crypto/crypto_user_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
In crypto_reportstat, a new skb is created by nlmsg_new(). This skb is
leaked if crypto_reportstat_alg() fails. Required release for skb is
added.
Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics")
Signed-off-by: Navid Emamdoost
---
crypto/crypto_user_stat.c | 4 +++-
1
On Fri, Oct 04, 2019 at 03:29:33PM +0200, Gert Robben wrote:
> Op 04-10-2019 om 08:16 schreef Ard Biesheuvel:
> > On Thu, 3 Oct 2019 at 23:26, Gert Robben wrote:
> > > Op 03-10-2019 om 15:39 schreef Ard Biesheuvel:
> > > > Commit 79c65d179a40e145 ("crypto: cbc - Convert to skcipher") updated
> > >
> From: linux-integrity-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Jarkko Sakkinen
> Sent: Friday, October 4, 2019 2:27 PM
> Subject: EXT: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()
>
> If you are able to call tpm_get_random(), the driver has already registered
> TP
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
> On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bottomley wrote:
> > > I think the principl
On Fri Oct 04 19, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 04:59:37PM -0700, James Bot
Op 04-10-2019 om 21:37 schreef Eric Biggers:
On Fri, Oct 04, 2019 at 03:29:33PM +0200, Gert Robben wrote:
Op 04-10-2019 om 08:16 schreef Ard Biesheuvel:
On Thu, 3 Oct 2019 at 23:26, Gert Robben wrote:
Op 03-10-2019 om 15:39 schreef Ard Biesheuvel:
Commit 79c65d179a40e145 ("crypto: cbc - Conv
On Fri, 2019-10-04 at 13:11 -0700, Jerry Snitselaar wrote:
> On Fri Oct 04 19, Jerry Snitselaar wrote:
> > On Fri Oct 04 19, James Bottomley wrote:
> > > On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
> > > > On Fri Oct 04 19, James Bottomley wrote:
> > > > > On Fri, 2019-10-04 at 21:22
91 matches
Mail list logo
