On Thu, 01 Aug 2019 09:04:11 +0300, Ard Biesheuvel said:
> The fact that crypto_aegis128_have_simd() does get optimized away, but
> crypto_aegis128_update_simd() doesn't (which is only called directly
> and not via a function pointer like the other two routines) makes me
> suspicious that this is
On Thu, 1 Aug 2019 at 08:47, Valdis Klētnieks wrote:
>
> On Thu, 01 Aug 2019 08:01:54 +0300, Ard Biesheuvel said:
>
> > > ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/aegis128.ko]
> > > undefined!
> > > ERROR: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
> > > ERROR: "cryp
On Thu, 01 Aug 2019 08:01:54 +0300, Ard Biesheuvel said:
> > ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/aegis128.ko] undefined!
> > ERROR: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
> > ERROR: "crypto_aegis128_encrypt_chunk_simd" [crypto/aegis128.ko] undefined!
> > make
On Wed, Jul 31, 2019 at 06:11:40PM -0700, Eric Biggers wrote:
>
> Well, it's either
>
> 1a. Remove the user's handle.
> OR
> 1b. Remove all users' handles. (FSCRYPT_REMOVE_KEY_FLAG_ALL_USERS)
>
> Then
>
> 2. If no handles remain, try to evict all inodes that use the key.
>
> By "purge
(+ Arnd)
On Thu, 1 Aug 2019 at 07:52, Valdis Klētnieks wrote:
>
> The recent NEON SIMD patches break the build if CONFIG_CRYPTO_AEGIS128_SIMD
> isn't set:
>
> MODPOST 558 modules
> ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/aegis128.ko] undefined!
> ERROR: "crypto_aegis128_update_simd
The recent NEON SIMD patches break the build if CONFIG_CRYPTO_AEGIS128_SIMD
isn't set:
MODPOST 558 modules
ERROR: "crypto_aegis128_decrypt_chunk_simd" [crypto/aegis128.ko] undefined!
ERROR: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
ERROR: "crypto_aegis128_encrypt_chunk_simd"
On Thu, Aug 01, 2019 at 11:53:46AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the crypto tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> scripts/Makefile.asm-generic:25: redundant generic-y found in
> arch/arm/include/asm/Kbuild: simd.h
>
> I
On Wed, Jul 31, 2019 at 07:38:43PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Jul 31, 2019 at 11:38:02AM -0700, Eric Biggers wrote:
> >
> > This is perhaps different from what users expect from unlink(). It's well
> > known
> > that unlink() just deletes the filename, not the file itself if it's s
On Wed, Jul 31, 2019 at 11:38:02AM -0700, Eric Biggers wrote:
>
> This is perhaps different from what users expect from unlink(). It's well
> known
> that unlink() just deletes the filename, not the file itself if it's still
> open
> or has other links. And unlink() by itself isn't meant for u
On Mon, Jul 29, 2019 at 12:58:28PM -0700, Eric Biggers wrote:
> On Sun, Jul 28, 2019 at 03:24:17PM -0400, Theodore Y. Ts'o wrote:
> > > +
> > > +/*
> > > + * Try to remove an fscrypt master encryption key. If other users have
> > > also
> > > + * added the key, we'll remove the current user's usa
On 7/30/19 1:28 PM, Hook, Gary wrote:
> Return and fail driver initialization if a DMA pool can't be
> allocated.
>
> Fixes: 4b394a232df7 ("crypto: ccp - Let a v5 CCP provide the same function as
> v3")
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/ccp-dev-v5.c | 1 +
> 1 file ch
Hi,
I just sent out a batch of 5 patches for crypto: inside-secure that
still contained some errors in the header (missing patch version,
incorrect e-mail address).
I resent the corrected version immediately thereafter, so please
ignore the first set of 5 (recognisable by having my old insides
While being a generic EIP97/EIP197 driver, the driver was only selectable
for Marvell Armada hardware. This fix makes the driver selectable for any
Device Tree supporting kernel configuration, allowing it to be used for
other compatible hardware by just adding the correct device tree entry.
It als
This patch adds support for a PCIE development board with FPGA from Xilinx,
to facilitate pre-silicon driver development by both Inside Secure and its
IP customers. Since Inside Secure neither produces nor has access to actual
silicon, this is required functionality to allow us to contribute.
Sign
Until now, the inside-secure driver required a set of firmware images
supplied by the silicon vendor, typically under NDA, to be present in
/lib/firmware/inside-secure in order to be able to function.
This patch removes the dependence on this official vendor firmware by
falling back to generic "min
This removes some code determine which engine has which algorithms which
was effectively redundant (may have been forward-looking?) due to always
enabling all algorithms for all currently supported engines.
A future patch will use a different, more scalable approach to achieve
this. This is removed
This is a first baby step towards making the inside-secure crypto driver
more broadly useful. The current driver only works for Marvell Armada HW
and requires proprietary firmware, only available under NDA from Marvell,
to be installed. This patch set allows the driver to be used with other
hardwar
This removes some code determine which engine has which algorithms which
was effectively redundant (may have been forward-looking?) due to always
enabling all algorithms for all currently supported engines.
A future patch will use a different, more scalable approach to achieve
this. This is removed
From: Pascal van Leeuwen
Until now, the inside-secure driver required a set of firmware images
supplied by the silicon vendor, typically under NDA, to be present in
/lib/firmware/inside-secure in order to be able to function.
This patch removes the dependence on this official vendor firmware by
f
From: Pascal van Leeuwen
This patch adds support for a PCIE development board with FPGA from Xilinx,
to facilitate pre-silicon driver development by both Inside Secure and its
IP customers. Since Inside Secure neither produces nor has access to actual
silicon, this is required functionality to al
This is a first baby step towards making the inside-secure crypto driver
more broadly useful. The current driver only works for Marvell Armada HW
and requires proprietary firmware, only available under NDA from Marvell,
to be installed. This patch set allows the driver to be used with other
hardwar
From: Pascal van Leeuwen
While being a generic EIP97/EIP197 driver, the driver was only selectable
for Marvell Armada hardware. This fix makes the driver selectable for any
Device Tree supporting kernel configuration, allowing it to be used for
other compatible hardware by just adding the correct
> -Original Message-
> From: Antoine Tenart
> Sent: Wednesday, July 31, 2019 4:46 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Pascal van Leeuwen
> ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au;
> da...@davemloft.net
> Subject: Re: [PATCHv2 3/3] crypto: inside-secur
On Wed, Jul 31, 2019 at 02:23:27PM +, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart
>
> > What happens if i < 2 ?
> >
> Ok, I did not consider that as it can't happen for any kind of legal FW. But
> it
> wouldn't be pretty (neither would 2 itself, BTW). I could throw an error for
> it
> -Original Message-
> From: Antoine Tenart
> Sent: Wednesday, July 31, 2019 2:26 PM
> To: Pascal van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bootlin.com;
> herb...@gondor.apana.org.au;
> da...@davemloft.net; Pascal Van Leeuwen
> Subject: Re: [PATCHv2 3/3] crypto: ins
> -Original Message-
> From: Antoine Tenart
> Sent: Wednesday, July 31, 2019 2:13 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Pascal van Leeuwen
> ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au;
> da...@davemloft.net
> Subject: Re: [PATCHv2 2/3] crypto: inside-secur
On 7/31/2019 4:06 PM, Iuliana Prodan wrote:
> Added inline helper functions to check authsize and assoclen for
> gcm, rfc4106 and rfc4543.
> Added, also, inline helper function to check key length for AES algorithms.
> These are used in the generic implementation of gcm/rfc4106/rfc4543
> and aes.
Check zero-length input, for skcipher algorithm, to solve the extra
tests. This is a valid operation, therefore the API will return no error.
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
---
drivers/crypto/caam/caamalg.c | 6 ++
drivers/crypto/caam/caamalg_qi.c | 3 +++
driv
To be consistent with other CAAM modules, caamhash should return 0
instead of -ENODEV in case CAAM has no MDHA.
Based on commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to
libraries")
the value returned by entry point is never checked and
the exit point is always executed.
Signed-
Update share descriptor for rfc4106 to skip instructions in case
cryptlen is zero. If no instructions are jumped the DECO hangs and a
timeout error is thrown.
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
---
drivers/crypto/caam/caamalg_desc.c | 47 ++--
From: Horia Geantă
skcipher encryption might fail and in some cases, like (invalid) input
length smaller then block size, updating the IV would lead to a useless
IV copy in case hardware issued an error.
Signed-off-by: Horia Geantă
Signed-off-by: Iuliana Prodan
---
drivers/crypto/caam/caamalg
From: Horia Geantă
Update alginfo struct to keep both virtual and dma key addresses,
so that descriptors have them at hand.
One example where this is needed is in the xcbc(aes) shared descriptors,
which are updated in current patch.
Another example is the upcoming fix for DKP.
Signed-off-by: Hor
From: Horia Geantă
Modify drive to provide a valid errno (and not the HW error ID)
to the user, via completion callbacks.
A "valid errno" is currently not explicitly mentioned in the docs,
however the error code is expected to match the one returned by the
generic SW implementation.
Note: in mo
To know if a registration succeeded added a new struct,
caam_akcipher_alg, that keeps, also, the registration status.
This status is updated in caam_pkc_init and verified in
caam_pkc_exit to unregister an algorithm.
Fixes: 1b46c90c8e00 ("crypto: caam - convert top level drivers to libraries")
Sign
Check key length to solve the extra tests that expect -EINVAL to be
returned when the key size is not valid.
Validated AES keylen for skcipher, ahash and aead.
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
---
Changes since v4:
- use, newly renamed, helper aes function, to validate ke
Check the return value of the hardware registration for caam_rng and free
resources in case of failure.
Fixes: e24f7c9e87d4 ("crypto: caam - hwrng support")
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
---
drivers/crypto/caam/caamrng.c | 5 -
1 file changed, 4 insertions(+), 1 de
From: Horia Geantă
Fuzz testing uncovered an issue when |user key| > |derived key|.
Derived key generation has to be fixed in two cases:
1. Era >= 6 (DKP is available)
DKP cannot be used with immediate input key if |user key| > |derived key|,
since the resulting descriptor (after DKP execution)
Commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to libraries")
changed entry and exit points behavior for caamalg,
caamalg_qi, caamalg_qi2, caamhash, caampkc, caamrng.
For example, previously caam_pkc_init() and caam_pkc_exit() were
module entry/exit points. This means that if an er
The series solves:
- the failures found with fuzz testing;
- resources clean-up on caampkc/caamrng exit path.
The first 10 patches solve the issues found with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.
They modify the drivers to provide a valid error (and not the hardware
error ID) to the user, vi
Check assoclen to solve the extra tests that expect -EINVAL to be
returned when the associated data size is not valid.
Validated assoclen for RFC4106 and RFC4543 which expects an assoclen
of 16 or 20.
Based on seqiv, IPsec ESP and RFC4543/RFC4106 the assoclen is sizeof IP
Header (spi, seq_no, exte
Check authsize to solve the extra tests that expect -EINVAL to be
returned when the authentication tag size is not valid.
Validated authsize for GCM, RFC4106 and RFC4543.
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
---
drivers/crypto/caam/caamalg.c | 13 +
drivers/c
From: Horia Geantă
ERN handler calls the caam/qi frontend "done" callback with a status
of -EIO. This is incorrect, since the callback expects a status value
meaningful for the crypto engine - hence the cryptic messages
like the one below:
platform caam_qi: 15: unknown error source
Fix this by p
Added inline helper functions to check authsize and assoclen for
gcm, rfc4106 and rfc4543.
Added, also, inline helper function to check key length for AES algorithms.
These are used in the generic implementation of gcm/rfc4106/rfc4543
and aes.
Changes since v2:
- rename aes helper functions with
Add inline helper function to check key length for AES algorithms.
The key can be 128, 192 or 256 bits size.
This function is used in the generic aes implementation.
Signed-off-by: Iuliana Prodan
---
include/crypto/aes.h | 17 +
lib/crypto/aes.c | 8
2 files changed
Added inline helper functions to check authsize and assoclen for
gcm, rfc4106 and rfc4543.
These are used in the generic implementation of gcm, rfc4106 and
rfc4543.
Signed-off-by: Iuliana Prodan
---
crypto/gcm.c | 41 ++-
include/crypto/gcm.h | 55
Hi Pascal,
On Wed, Jul 31, 2019 at 08:10:54AM +0200, Pascal van Leeuwen wrote:
> This patch removes a DES key size check that is redundant as it is already
> performed by the crypto API itself due to min_keysize = max_keysize.
>
> Signed-off-by: Pascal van Leeuwen
Acked-by: Antoine Tenart
Tha
Hi Pascal,
Thanks for reworking this not to include the firmware blob, the patch
looks good and I only have minor comments.
On Fri, Jul 26, 2019 at 02:43:25PM +0200, Pascal van Leeuwen wrote:
> +
> +static int eip197_write_firmware(struct safexcel_crypto_priv *priv,
> +
Hi Pascal,
On Tue, Jul 30, 2019 at 04:17:54PM +, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart
> > On Tue, Jul 30, 2019 at 10:20:43AM +, Pascal Van Leeuwen wrote:
> > > > On Fri, Jul 26, 2019 at 02:43:24PM +0200, Pascal van Leeuwen wrote:
> > > > > - switch (priv->version) {
> >
On Tue, Jul 23, 2019 at 03:19:36PM +0800, Chuhong Yuan wrote:
>
> Use devm_hwrng_register to get rid of manual
> unregistration.
>
> Signed-off-by: Chuhong Yuan
Acked-by: Ludovic Desroches
Thanks
> ---
> drivers/crypto/atmel-sha204a.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
On Wed, Jul 31, 2019 at 11:37:08AM +, Pascal Van Leeuwen wrote:
>
> > In general we want to maximise compiler coverage under all config
> > options so if we can make it compiler without too much effort that
> > would be the preferred solution.
> >
> I understand that, and I tried to do that ini
On Thu, Jul 25, 2019 at 04:01:55PM +0800, Chuhong Yuan wrote:
> External E-Mail
>
>
> Use devm_hwrng_register to simplify the implementation.
> Manual unregistration and some remove functions can be
> removed now.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/char/hw_random/atmel-rng.c |
> -Original Message-
> From: Herbert Xu
> Sent: Wednesday, July 31, 2019 1:08 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Pascal van Leeuwen
> ; linux-crypto@vger.kernel.org; da...@davemloft.net
> Subject: Re: [PATCHv2 2/3] crypto: inside-secure - add support for PCI based
> FPGA
On Wed, Jul 31, 2019 at 10:11:46AM +, Pascal Van Leeuwen wrote:
>
> > > > +static int __init crypto_is_init(void)
> > > > +{
> > > > + int rc;
> > > > +
> > > > + #if (IS_ENABLED(CONFIG_OF))
> > > > + /* Register platform driver */
> > > > + platform_driv
On Fri, Jul 26, 2019 at 09:19:04PM +0300, Ard Biesheuvel wrote:
> The newly introduced AES library exposes aes_encrypt/aes_decrypt
> routines so rename existing occurrences of those identifiers in
> the s390 driver.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/s390/crypto/aes_s390.c | 8 --
On Wed, Jul 31, 2019 at 10:19:30AM +0200, Hans de Goede wrote:
> On 30-07-19 22:07, Eric Biggers wrote:
>
> >Well, seems like the solution needs to involve unifying the implementations.
> >
> >Note that Ard Biesheuvel recently added the arc4 and aes algorithms to
> >lib/crypto/, with options CONFIG
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Pascal Van Leeuwen
> Sent: Tuesday, July 30, 2019 12:21 PM
> To: Antoine Tenart ; Pascal van Leeuwen
>
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au;
> da...@davemloft.net
> Subject: RE:
On Wed, Jul 31, 2019 at 01:48:33AM +0530, Amit Pundir wrote:
> From: Wen Yang
>
> commit 95566aa75cd6b3b404502c06f66956b5481194b3 upstream.
>
> There is a possible double free issue in ppc4xx_trng_probe():
>
> 85: dev->trng_base = of_iomap(trng, 0);
> 86: of_node_put(trng); ---> re
On Wed, 31 Jul 2019 at 11:35, Iuliana Prodan wrote:
>
> On 7/31/2019 8:33 AM, Ard Biesheuvel wrote:
> > On Tue, 30 Jul 2019 at 13:33, Iuliana Prodan wrote:
> >>
> >> Add inline helper function to check key length for AES algorithms.
> >> The key can be 128, 192 or 256 bits size.
> >> This functio
On 7/31/2019 8:33 AM, Ard Biesheuvel wrote:
> On Tue, 30 Jul 2019 at 13:33, Iuliana Prodan wrote:
>>
>> Add inline helper function to check key length for AES algorithms.
>> The key can be 128, 192 or 256 bits size.
>> This function is used in the generic aes implementation.
>>
>> Signed-off-by: I
Hi,
On 30-07-19 22:07, Eric Biggers wrote:
On Tue, Jul 30, 2019 at 06:07:54PM +0200, Hans de Goede wrote:
Hi,
On 30-07-19 18:03, Eric Biggers wrote:
On Tue, Jul 30, 2019 at 03:15:35PM +0200, Stephan Mueller wrote:
Am Dienstag, 30. Juli 2019, 14:38:35 CEST schrieb Hans de Goede:
Hi Hans,
F
This patch removes a DES key size check that is redundant as it is already
performed by the crypto API itself due to min_keysize = max_keysize.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_cipher.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/cry
61 matches
Mail list logo
