Re: [PATCH] crypto: dh - fix memory leak
On Tue, Jul 10, 2018 at 09:22:52AM -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *base* were allocated, release them
> before return.
>
> Addresses-Coverity-ID: 1471702 ("Resource leak")
> Fixes: e3fe0ae12962 ("crypto: dh - add public key verification test")
> Signed-off-by: Gustavo A. R. Silva
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable
On Thu, Jul 19, 2018 at 10:57:16PM +0200, Stephan Müller wrote: > > Therefore, I am not sure that either having an SGL interface for the RNG API > or a virtual address interface for the sync skcipher would be helpful. Could you please explain again why a virtual address interface to sync skcipher algorithms won't be useful? It's something that others have asked for in the past too. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable
On Tue, Jul 10, 2018 at 05:57:00PM +0200, Stephan Müller wrote: > The SGL can directly operate caller-provided memory with the exception > of stack memory. The DRBG detects whether the caller provided > non-suitable memory and uses the scratchpad only on those circumstances. > > This patch increases the speed of the CTR DRBG by 1 to 3 percent > depending on the buffer size of the output buffer. > > Signed-off-by: Stephan Mueller I think this is an abuse of virt_addr_valid. It's meant to catch bogus uses of SG lists, it's not meant to be a guarantee that an address can be used on an SG list. A better solution would be either an SG-list interface for rng, or alternatively a virtual address interface for sync skcipher. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: dh - fix calculating encoded key size
On Wed, Jul 11, 2018 at 09:27:56AM -0700, Eric Biggers wrote: > > The callers do check for errors, but at the point of the proposed BUG_ON() a > buffer overflow may have already occurred, so I think a BUG_ON() would be more > appropriate than a WARN_ON(). Of course, it would be better to prevent any > buffer overflow from occurring in the first place, but that's already the > purpose of the 'len != crypto_dh_key_len(params)' check; the issue was that > 'crypto_dh_key_len()' calculated the wrong length. How about adding an end argument to dh_pack_data so that it can check that the buffer isn't overflown each time it's called? Then if you cared you could also have one final check at the end of the function to ensure the buffer is fully used. As we can easily avoid having a BUG_ON here I think we should since a BUG_ON would leave the machine unresponsive which should be a last resort. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v1 0/5] crypto: ccp - Driver updates 2018-07-03
On Tue, Jul 03, 2018 at 12:11:22PM -0500, Tom Lendacky wrote: > The following patches for the PSP support within the CCP driver are > included in this driver update series: > > - Fix a possible race condition when checking for command completion > - Add a message to indicate if the PSP function has been enabled > - In preparation for moving register offsets into the version data, > remove unused register definitions > - Add support for putting register offsets in the version data. This > is needed as a new device (to be added in the next patch) has > different offsets for the registers. > - Add support for a new CCP/PSP device ID > > This patch series is based on cryptodev-2.6. > > --- > > Tom Lendacky (5): > crypto: ccp: Fix command completion detection race > crypto: ccp: Add psp enabled message when initialization succeeds > crypto: ccp: Remove unused #defines > crypto: ccp: Support register differences between PSP devices > crypto: ccp: Add support for new CCP/PSP device ID > > > drivers/crypto/ccp/psp-dev.c | 32 +--- > drivers/crypto/ccp/psp-dev.h | 19 +-- > drivers/crypto/ccp/sp-dev.h |7 ++- > drivers/crypto/ccp/sp-pci.c | 36 ++-- > 4 files changed, 54 insertions(+), 40 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: padlock-aes - Fix Nano workaround data corruption
This was detected by the self-test thanks to Ard's chunking patch.
I finally got around to testing this out on my ancient Via box. It
turns out that the workaround got the assembly wrong and we end up
doing count + initial cycles of the loop instead of just count.
This obviously causes corruption, either by overwriting the source
that is yet to be processed, or writing over the end of the buffer.
On CPUs that don't require the workaround only ECB is affected.
On Nano CPUs both ECB and CBC are affected.
This patch fixes it by doing the subtraction prior to the assembly.
Fixes: a76c1c23d0c3 ("crypto: padlock-aes - work around Nano CPU...")
Cc:
Reported-by: Jamie Heilman
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 1c6cbda..09d823d 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -266,6 +266,8 @@ static inline void padlock_xcrypt_ecb(const u8 *input, u8
*output, void *key,
return;
}
+ count -= initial;
+
if (initial)
asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep
xcryptecb */
: "+S"(input), "+D"(output)
@@ -273,7 +275,7 @@ static inline void padlock_xcrypt_ecb(const u8 *input, u8
*output, void *key,
asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
: "+S"(input), "+D"(output)
- : "d"(control_word), "b"(key), "c"(count - initial));
+ : "d"(control_word), "b"(key), "c"(count));
}
static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
@@ -284,6 +286,8 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8
*output, void *key,
if (count < cbc_fetch_blocks)
return cbc_crypt(input, output, key, iv, control_word, count);
+ count -= initial;
+
if (initial)
asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep
xcryptcbc */
: "+S" (input), "+D" (output), "+a" (iv)
@@ -291,7 +295,7 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8
*output, void *key,
asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep xcryptcbc */
: "+S" (input), "+D" (output), "+a" (iv)
- : "d" (control_word), "b" (key), "c" (count-initial));
+ : "d" (control_word), "b" (key), "c" (count));
return iv;
}
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: dh - fix calculating encoded key size
On Tue, Jul 10, 2018 at 08:59:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> causing an out-of-bounds write of 4 bytes in crypto_dh_encode_key(), and
> an out-of-bounds read of 4 bytes in crypto_dh_decode_key(). Fix it.
> Also add a BUG_ON() if crypto_dh_encode_key() doesn't exactly fill the
> buffer, as that would have found this bug without resorting to KASAN.
>
> Reported-by: syzbot+6d38d558c25b53b8f...@syzkaller.appspotmail.com
> Fixes: e3fe0ae12962 ("crypto: dh - add public key verification test")
> Signed-off-by: Eric Biggers
Is it possible to return an error and use WARN_ON instead of BUG_ON?
Or do the callers not bother to check for errors?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/6] crypto: fixes and cleanups
On Sun, Jul 01, 2018 at 08:02:33AM +0100, Gilad Ben-Yossef wrote: > The patch set fixes ccree IV handling, finup() operation (provided > by Hadar Gat) and CTS-AES mode of operation along a code cleanup. > > > > Since our finup() method was obviously broken but was not detected > > by testmgr, I've added finup() test to testmgr to catch it next > > time it happened. > > Changes from v1: > - Add missing "static" qualifier reported by kbuild bot > - Add CTS-AES fix and some more cleanups > > > Gilad Ben-Yossef (5): > crypto: testmgr: add hash finup tests > crypto: ccree: fix iv handling > crypto: ccree: remove dead legacy code > crypto: ccree: use CBC-CS3 CTS mode > crypto: ccree: rate limit debug print > > Hadar Gat (1): > crypto: ccree: fix finup > > crypto/testmgr.c | 55 +--- > drivers/crypto/ccree/cc_cipher.c | 137 > +-- > drivers/crypto/ccree/cc_driver.c | 4 +- > drivers/crypto/ccree/cc_hash.c | 81 +---------- > 4 files changed, 153 insertions(+), 124 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/6] crypto: remove redundant type specifications
On Sat, Jun 30, 2018 at 03:16:10PM -0700, Eric Biggers wrote: > Originally, algorithms had to declare their type in .cra_flags as a > CRYPTO_ALG_TYPE_* value. Some types of algorithms such as "cipher" > still have to do this. But now most algorithm types use different > top-level C data structures, and different registration and allocation > functions. And for these, the core crypto API automatically sets the > .cra_flags type as well as .cra_type, mainly for its own use (users > shouldn't care about these). > > Yet, many algorithms are still explicitly setting their .cra_flags type > and sometimes even .cra_type, which is confusing as this actually does > nothing. Apparently, people are just copy-and-pasting this from > existing code without understanding it. > > Therefore, this patchset removes the useless initializations, as well as > useless type flags passed to the strongly-typed tfm allocators. > > This doesn't change any actual behavior, AFAIK. > > For now I didn't bother with 'blkcipher' and 'ablkcipher' algorithms, > since those should eventually be migrated to 'skcipher' anyway. > > Eric Biggers (6): > crypto: shash - remove useless setting of type flags > crypto: ahash - remove useless setting of type flags > crypto: ahash - remove useless setting of cra_type > crypto: aead - remove useless setting of type flags > crypto: skcipher - remove useless setting of type flags > crypto: remove redundant type flags from tfm allocation All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/sha256-mb - fix digest copy in sha256_mb_mgr_get_comp_job_avx2()
On Fri, Jun 29, 2018 at 02:14:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There is a copy-paste error where sha256_mb_mgr_get_comp_job_avx2()
> copies the SHA-256 digest state from sha256_mb_mgr::args::digest to
> job_sha256::result_digest. Consequently, the sha256_mb algorithm
> sometimes calculates the wrong digest. Fix it.
>
> Reproducer using AF_ALG:
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> static const __u8 expected[32] =
> "\xad\x7f\xac\xb2\x58\x6f\xc6\xe9\x66\xc0\x04\xd7\xd1\xd1\x6b\x02"
> "\x4f\x58\x05\xff\x7c\xb4\x7c\x7a\x85\xda\xbd\x8b\x48\x89\x2c\xa7";
>
> int main()
> {
> int fd;
> struct sockaddr_alg addr = {
> .salg_type = "hash",
> .salg_name = "sha256_mb",
> };
> __u8 data[4096] = { 0 };
> __u8 digest[32];
> int ret;
> int i;
>
> fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(fd, (void *), sizeof(addr));
> fork();
> fd = accept(fd, 0, 0);
> do {
> ret = write(fd, data, 4096);
> assert(ret == 4096);
> ret = read(fd, digest, 32);
> assert(ret == 32);
> } while (memcmp(digest, expected, 32) == 0);
>
> printf("wrong digest: ");
> for (i = 0; i < 32; i++)
> printf("%02x", digest[i]);
> printf("\n");
> }
>
> Output was:
>
> wrong digest:
> ad7facb2ffef7cb47c7a85dabd8b48892ca7
>
> Fixes: 172b1d6b5a93 ("crypto: sha256-mb - fix ctx pointer and digest copy")
> Cc: # v4.8+
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: MAINTAINERS - fix file path for SHA multibuffer code
On Fri, Jun 29, 2018 at 02:21:11PM -0700, Eric Biggers wrote: > From: Eric Biggers > > "arch/x86/crypto/sha*-mb" needs a trailing slash, since it refers to > directories. Otherwise get_maintainer.pl doesn't find the entry. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: decrease priority of multibuffer SHA algorithms
On Fri, Jun 29, 2018 at 05:01:40PM -0700, Eric Biggers wrote: > From: Eric Biggers > > I found that not only was sha256_mb sometimes computing the wrong digest > (fixed by a separately sent patch), but under normal workloads it's > hundreds of times slower than sha256-avx2, due to the flush delay. The > same applies to sha1_mb and sha512_mb. Yet, currently these can be the > highest priority implementations and therefore used by default. > Therefore, this series decreases their priority so that users have to > more explicitly opt-in to using them. > > Note that I don't believe the status quo of just having them behind > kernel config options is sufficient, since people often aren't familiar > with all the crypto options and error on the side of enabling too many. > And it's especially unexpected that enabling an "optimized" > implementation would actually make things 1000 times slower. > > Eric Biggers (4): > crypto: sha1_generic - add cra_priority > crypto: sha256_generic - add cra_priority > crypto: sha512_generic - add cra_priority > crypto: x86/sha-mb - decrease priority of multibuffer algorithms > > arch/x86/crypto/sha1-mb/sha1_mb.c | 9 - > arch/x86/crypto/sha256-mb/sha256_mb.c | 9 - > arch/x86/crypto/sha512-mb/sha512_mb.c | 9 - > crypto/sha1_generic.c | 1 + > crypto/sha256_generic.c | 2 ++ > crypto/sha512_generic.c | 2 ++ > 6 files changed, 29 insertions(+), 3 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: inside-secure - support more algorithms
On Thu, Jun 28, 2018 at 05:21:52PM +0200, Antoine Tenart wrote: > Hi all, > > This series adds support for more algorithms in the Inside Secure > SafeXcel cryptographic engine driver. Those new algorithms are: > - MD5 (and its hmac). > - DES (ECB and CBC). > - 3DES (ECB and CBC). > > The last patch was made on top of the algorithm additions, to enhance > the driver's performances. > > This series should be applied on top of another one: > https://lkml.org/lkml/2018/6/28/516 > > Thanks! > Antoine > > Ofer Heifetz (5): > crypto: inside-secure - md5 support > crypto: inside-secure - hmac(md5) support > crypto: inside-secure - ecb(des) and cbc(des) support > crypto: inside-secure - ecb(des3_ede) and cbc(des3_ede) support > crypto: inside-secure - remove request list to improve performance > > drivers/crypto/Kconfig| 2 + > drivers/crypto/inside-secure/safexcel.c | 100 ++--- > drivers/crypto/inside-secure/safexcel.h | 41 +- > .../crypto/inside-secure/safexcel_cipher.c| 369 ++ > drivers/crypto/inside-secure/safexcel_hash.c | 157 ++-- > drivers/crypto/inside-secure/safexcel_ring.c | 48 ++- > 6 files changed, 553 insertions(+), 164 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ECDH - add public key verification test
On Mon, Jun 25, 2018 at 12:00:18PM +0200, Stephan Müller wrote: > According to SP800-56A section 5.6.2.1, the public key to be processed > for the ECDH operation shall be checked for appropriateness. When the > public key is considered to be an ephemeral key, the partial validation > test as defined in SP800-56A section 5.6.2.3.4 can be applied. > > The partial verification test requires the presence of the field > elements of a and b. For the implemented NIST curves, b is defined in > FIPS 186-4 appendix D.1.2. The element a is implicitly given with the > Weierstrass equation given in D.1.2 where a = p - 3. > > Without the test, the NIST ACVP testing fails. After adding this check, > the NIST ACVP testing passes. > > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm/speck - fix building in Thumb2 mode
On Mon, Jun 18, 2018 at 03:33:23PM -0700, Eric Biggers wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here --
> `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here --
> `bic sp,#0xf'
>
> The problem is that the 'bic' instruction can't operate on the 'sp'
> register in Thumb2 mode. Fix it by using a temporary register. This
> isn't in the main loop, so the performance difference is negligible.
> This also matches what aes-neonbs-core.S does.
>
> Reported-by: Stefan Agner
> Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation
> of Speck-XTS")
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: vmac - various fixes
On Mon, Jun 18, 2018 at 10:22:36AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Hi, this series fixes various bugs in the VMAC template (crypto/vmac.c). > First, the per-request context was being stored in the transform > context, which made VMAC not thread-safe, and the kernel could be > crashed by using the same VMAC transform in multiple threads using > AF_ALG (found by syzkaller). Also the keys were incorrectly being wiped > after each message. Patch 2 fixes these bugs, Cc'ed to stable. > > But there are also bugs that require breaking changes: the nonce is > hardcoded to 0, and the endianness of the final digest is wrong. So > patch 3 introduces a fixed version of the VMAC template that takes the > nonce as the first 16 bytes of data, and fixes the digest endianness. > > Patch 4 then removes the current version of the VMAC template. I'm not > 100% sure whether we can really do that or not as it may have users > (there are no explicit users in the kernel, though), but given that the > old version was insecure unless a unique key was set for each message, I > think we should try and see if anyone complains. > > Eric Biggers (4): > crypto: vmac - require a block cipher with 128-bit block size > crypto: vmac - separate tfm and request context > crypto: vmac - add nonced version with big endian digest > crypto: vmac - remove insecure version with hardcoded nonce > > crypto/tcrypt.c | 2 +- > crypto/testmgr.c | 4 +- > crypto/testmgr.h | 217 + > crypto/vmac.c | 444 -- > include/crypto/vmac.h | 63 -- > 5 files changed, 351 insertions(+), 379 deletions(-) > delete mode 100644 include/crypto/vmac.h All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium: make structure algs static
On Fri, Jun 01, 2018 at 02:12:27PM +0100, Colin King wrote: > From: Colin Ian King > > The structure algs is local to the source and does not need to be in > global scope, so make it static. > > Cleans up sparse warning: > drivers/crypto/cavium/cpt/cptvf_algs.c:354:19: warning: symbol 'algs' > was not declared. Should it be static? > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel-ecc - fix to allow multi segment scatterlists
On Wed, Jun 13, 2018 at 04:29:58PM +0300, Tudor Ambarus wrote:
> Remove the limitation of single element scatterlists. ECDH with
> multi-element scatterlists is needed by TPM.
>
> Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi
> segment scatterlists")'.
>
> Signed-off-by: Tudor Ambarus
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/10] crypto: inside-secure - sha512/384 support
On Tue, May 29, 2018 at 02:13:42PM +0200, Antoine Tenart wrote: > Hello Herbert, > > This series adds support for the SHA512 and SHA384 algorithms in the > Inside Secure SafeXcel driver. Variants of those two algorithms are also > added as well (hmac, and AEAD). > > Before doing so a few patches rework the driver to prepare for the new > algorithms additions. > > Thanks! > Antoine > > Antoine Tenart (10): > crypto: inside-secure - use the error handler for invalidation > requests > crypto: inside-secure - improve the counter computation > crypto: sha512_generic - add a sha512 0-length pre-computed hash > crypto: inside-secure - sha512 support > crypto: inside-secure - hmac(sha512) support > crypto: inside-secure - authenc(hmac(sha512),cbc(aes)) support > crypto: sha512_generic - add a sha384 0-length pre-computed hash > crypto: inside-secure - sha384 support > crypto: inside-secure - hmac(sha384) support > crypto: inside-secure - authenc(hmac(sha384),cbc(aes)) support > > crypto/sha512_generic.c | 22 + > drivers/crypto/inside-secure/safexcel.c | 6 + > drivers/crypto/inside-secure/safexcel.h | 23 +- > .../crypto/inside-secure/safexcel_cipher.c| 89 +++- > drivers/crypto/inside-secure/safexcel_hash.c | 381 -- > include/crypto/sha.h | 4 + > 6 files changed, 469 insertions(+), 56 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel-ecc - remove overly verbose dev_info
On Wed, Jun 13, 2018 at 04:29:59PM +0300, Tudor Ambarus wrote:
> Remove it because when using a slow console, it can affect
> the speed of crypto operations.
>
> Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly
> verbose printk from AES XTS init")'.
>
> Signed-off-by: Tudor Ambarus
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: don't optimize keccakf()
On Fri, Jun 08, 2018 at 11:53:41AM +0200, Dmitry Vyukov wrote:
> keccakf() is the only function in kernel that uses __optimize() macro.
> __optimize() breaks frame pointer unwinder as optimized code uses RBP,
> and amusingly this always lead to degraded performance as gcc does not
> inline across different optimizations levels, so keccakf() wasn't inlined
> into its callers and keccakf_round() wasn't inlined into keccakf().
>
> Drop __optimize() to resolve both problems.
>
> Signed-off-by: Dmitry Vyukov
> Fixes: 83dee2ce1ae7 ("crypto: sha3-generic - rewrite KECCAK transform to help
> the compiler optimize")
> Reported-by: syzbot+37035ccfa9a0a017f...@syzkaller.appspotmail.com
> Reported-by: syzbot+e073e4740cfbb3ae2...@syzkaller.appspotmail.com
> Cc: linux-crypto@vger.kernel.org
> Cc: "David S. Miller"
> Cc: Herbert Xu
> Cc: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin,_end
Jia He wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [7.035106] 1 lock held by cryptomgr_test/410:
> [7.039549] #0: (ptrval) (>drbg_mutex){+.+.}, at:
> drbg_instantiate+0x34/0x398
> [7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
> 4.17.0-rc6+ #27
> [7.068228] dump_backtrace+0x0/0x1c0
> [7.071890] show_stack+0x24/0x30
> [7.075208] dump_stack+0xb0/0xec
> [7.078523] ___might_sleep+0x160/0x238
> [7.082360] skcipher_walk_done+0x118/0x2c8
> [7.086545] ctr_encrypt+0x98/0x130
> [7.090035] simd_skcipher_encrypt+0x68/0xc0
> [7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
> [7.098400] drbg_ctr_update+0x98/0x330
> [7.102236] drbg_seed+0x1b8/0x2f0
> [7.105637] drbg_instantiate+0x2ac/0x398
> [7.109646] drbg_kcapi_seed+0xbc/0x188
> [7.113482] crypto_rng_reset+0x4c/0xb0
> [7.117319] alg_test_drbg+0xec/0x330
> [7.120981] alg_test.part.6+0x1c8/0x3c8
> [7.124903] alg_test+0x58/0xa0
> [7.128044] cryptomgr_test+0x50/0x58
> [7.131708] kthread+0x134/0x138
> [7.134936] ret_from_fork+0x10/0x1c
>
> Seems there is a bug in Ard Biesheuvel's commit.
> Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
> en/disable into loop")
>
> [1] https://www.spinics.net/lists/linux-crypto/msg33103.html
>
> Signed-off-by: jia...@hxt-semitech.com
> Acked-by: Ard Biesheuvel
> Cc: # 4.17
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: morus640 - Fix out-of-bounds access
On Wed, Jun 13, 2018 at 04:44:17PM +0200, Ondrej Mosnacek wrote:
> We must load the block from the temporary variable here, not directly
> from the input.
>
> Also add forgotten zeroing-out of the uninitialized part of the
> temporary block (as is done correctly in morus1280.c).
>
> Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations")
> Reported-by: syzbot+1fafa9c4cf42df33f...@syzkaller.appspotmail.com
> Reported-by: syzbot+d82643ba80bf6937c...@syzkaller.appspotmail.com
> Signed-off-by: Ondrej Mosnacek
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V3 1/2] evm: Don't deadlock if a crypto algorithm is unavailable
On Fri, Jun 08, 2018 at 02:57:42PM -0700, Matthew Garrett wrote: > When EVM attempts to appraise a file signed with a crypto algorithm the > kernel doesn't have support for, it will cause the kernel to trigger a > module load. If the EVM policy includes appraisal of kernel modules this > will in turn call back into EVM - since EVM is holding a lock until the > crypto initialisation is complete, this triggers a deadlock. Add a > CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag > in the EVM case in order to fail gracefully with an error message > instead of deadlocking. > > Signed-off-by: Matthew Garrett Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V2 1/2] evm: Don't deadlock if a crypto algorithm is unavailable
On Wed, Jun 06, 2018 at 02:57:11PM -0700, Matthew Garrett wrote: > When EVM attempts to appraise a file signed with a crypto algorithm the > kernel doesn't have support for, it will cause the kernel to trigger a > module load. If the EVM policy includes appraisal of kernel modules this > will in turn call back into EVM - since EVM is holding a lock until the > crypto initialisation is complete, this triggers a deadlock. Add a > CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag > in the EVM case in order to fail gracefully with an error message > instead of deadlocking. > > Signed-off-by: Matthew Garrett > --- > crypto/api.c| 2 +- > include/linux/crypto.h | 5 + > security/integrity/evm/evm_crypto.c | 3 ++- > 3 files changed, 8 insertions(+), 2 deletions(-) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] evm: Don't deadlock if a crypto algorithm is unavailable
On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote: > Trying to instantiate a non-existent crypto algorithm will cause the > kernel to trigger a module load. If EVM appraisal is enabled, this will > in turn trigger appraisal of the module, which will fail because the > crypto algorithm isn't available. Add a CRYPTO_NOLOAD flag and skip > module loading if it's set, and add that flag in the EVM case. > > Signed-off-by: Matthew Garrett I don't get it. Without your patch it will fail because the EVM appraisal fails. With your patch it will fail because there is no algorithm registered. So what's the difference? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: remove x86 salsa20 implementations
On Sat, May 26, 2018 at 12:08:57AM -0700, Eric Biggers wrote: > Hello, > > The x86 asm implementations of Salsa20 have been missed so far in the > fixes to stop abusing %ebp/%rbp in asm code to get correct stack traces. > This has been causing the unwinder warnings reported by syzkaller to > continue. > > This series "fixes" it by just removing the offending salsa20-asm > implementations, which as far as I can tell are basically useless these > days; the x86_64 asm version in particular isn't actually any faster > than the C version anymore. (And possibly no one even uses these > anyway.) See the patch for the full explanation. > > Eric Biggers (2): > crypto: x86/salsa20 - remove x86 salsa20 implementations > crypto: salsa20 - Revert "crypto: salsa20 - export generic helpers" > > arch/x86/crypto/Makefile| 4 - > arch/x86/crypto/salsa20-i586-asm_32.S | 938 > arch/x86/crypto/salsa20-x86_64-asm_64.S | 805 > arch/x86/crypto/salsa20_glue.c | 91 --- > crypto/Kconfig | 28 - > crypto/salsa20_generic.c| 20 +- > include/crypto/salsa20.h| 27 - > 7 files changed, 13 insertions(+), 1900 deletions(-) > delete mode 100644 arch/x86/crypto/salsa20-i586-asm_32.S > delete mode 100644 arch/x86/crypto/salsa20-x86_64-asm_64.S > delete mode 100644 arch/x86/crypto/salsa20_glue.c > delete mode 100644 include/crypto/salsa20.h All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto:chelsio: Fixes and cleanup
On Thu, May 24, 2018 at 05:26:36PM +0530, Harsh Jain wrote: > It includes Fixes and cleanup . > > Harsh Jain (3): > crypto:chelsio:Return -ENOSPC for transient busy indication. > crypt:chelsio:Send IV as Immediate for cipher algo > crypto:chelsio: Remove separate buffer used for DMA map B0 block in > CCM > > drivers/crypto/chelsio/chcr_algo.c | 303 > +++ > drivers/crypto/chelsio/chcr_algo.h | 3 +- > drivers/crypto/chelsio/chcr_core.h | 2 +- > drivers/crypto/chelsio/chcr_crypto.h | 15 +- > 4 files changed, 140 insertions(+), 183 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: clarify licensing of OpenSSL asm code
On Tue, May 22, 2018 at 12:35:11PM -0700, Adam Langley wrote: > Several source files have been taken from OpenSSL. In some of them a > comment that "permission to use under GPL terms is granted" was > included below a contradictory license statement. In several cases, > there was no indication that the license of the code was compatible > with the GPLv2. > > This change clarifies the licensing for all of these files. I've > confirmed with the author (Andy Polyakov) that a) he has licensed the > files with the GPLv2 comment under that license and b) that he's also > happy to license the other files under GPLv2 too. In one case, the > file is already contained in his CRYPTOGAMS bundle, which has a GPLv2 > option, and so no special measures are needed. > > In all cases, the license status of code has been clarified by making > the GPLv2 license prominent. > > The .S files have been regenerated from the updated .pl files. > > This is a comment-only change. No code is changed. > > Signed-off-by: Adam Langley Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/3] crypto: caam - fix MC firmware detection
On Wed, May 23, 2018 at 02:32:40PM +0300, Horia Geantă wrote:
> Management Complex (MC) f/w detection is based on CTPR_MS[DPAA2] bit.
>
> This is incorrect since:
> -the bit is set for all CAAM blocks integrated in SoCs with a certain
> Layerscape Chassis
> -some SoCs with LS Chassis don't have an MC block (thus no MC f/w)
>
> To fix this, MC f/w detection will be based on the presence of
> "fsl,qoriq-mc" compatible string in the device tree.
>
> Fixes: 297b9cebd2fc0 ("crypto: caam/jr - add support for DPAA2 parts")
> Signed-off-by: Horia Geantă
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: Mark MORUS SIMD glue as x86-specific
On Mon, May 21, 2018 at 09:41:51PM +0200, Ondrej Mosnáček wrote:
> From: Ondrej Mosnacek
>
> Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for
> MORUS") accidetally consiedered the glue code to be usable by different
> architectures, but it seems to be only usable on x86.
>
> This patch moves it under arch/x86/crypto and adds 'depends on X86' to
> the Kconfig options and also removes the prompt to hide these internal
> options from the user.
>
> Reported-by: kbuild test robot
> Signed-off-by: Ondrej Mosnacek
> ---
> arch/x86/crypto/Makefile | 3 +++
> {crypto => arch/x86/crypto}/morus1280_glue.c | 4 ++--
> {crypto => arch/x86/crypto}/morus640_glue.c | 4 ++--
> crypto/Kconfig | 6 --
> crypto/Makefile | 2 --
> 5 files changed, 11 insertions(+), 8 deletions(-)
> rename {crypto => arch/x86/crypto}/morus1280_glue.c (98%)
> rename {crypto => arch/x86/crypto}/morus640_glue.c (98%)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: eliminate redundant decryption test vectors
On Sun, May 20, 2018 at 10:50:24PM -0700, Eric Biggers wrote: > Hello, > > When adding the Speck cipher support I was annoyed by having to add both > encryption and decryption test vectors, since they are redundant: the > decryption ones are just the encryption ones with the input and result > flipped. > > It turns out that's nearly always the case for all the other > ciphers/skciphers too. A few have slight differences, but they seem to > be accidental except for "kw(aes)", and we can still handle "kw(aes)" > nearly as easily with just one copy of the test vectors. > > Therefore, this series removes all the decryption cipher_testvecs and > updates testmgr to test both encryption and decryption using what used > to be the encryption test vectors. I did not change any of the AEAD > test vectors, though a similar change could be made for them too. > > Patches 1-4 add some encryption test vectors, just so no test coverage > is lost. Patch 5 is the real patch. Due to the 1+ lines deleted > from testmgr.h, the patch file is 615 KB so it may be too large for the > mailing list. You can also grab the series from git: > https://github.com/ebiggers/linux, branch "test_vector_redundancy_v1" > (HEAD is a09e48518f957bb61bb278227917eaad64cf13be). Most of the patch > is scripted, but there are also some manual changes, mostly to > testmgr.c. For review purposes, in case the full 615 KB patch doesn't > reach the mailing list, I'm also pasting an abbreviated version of the > patch below that excludes the scripted changes to testmgr.h, i.e. it > only includes my manual changes on top of the scripted changes. > > Eric Biggers (5): > crypto: testmgr - add extra ecb(des) encryption test vectors > crypto: testmgr - make an cbc(des) encryption test vector chunked > crypto: testmgr - add extra ecb(tnepres) encryption test vectors > crypto: testmgr - add extra kw(aes) encryption test vector > crypto: testmgr - eliminate redundant decryption test vectors > > crypto/testmgr.c | 409 +- > crypto/testmgr.h | 12227 ++++- > 2 files changed, 954 insertions(+), 11682 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/aegis256 - Fix wrong key buffer size
On Sun, May 20, 2018 at 10:57:23AM +0200, Ondrej Mosnáček wrote:
> From: Ondrej Mosnacek <omosna...@gmail.com>
>
> AEGIS-256 key is two blocks, not one.
>
> Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
> Reported-by: Eric Biggers <ebigge...@gmail.com>
> Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/6] crypto: crc32 cleanups and unkeyed tests
On Sat, May 19, 2018 at 10:07:36PM -0700, Eric Biggers wrote: > This series fixes up alignment for crc32-generic and crc32c-generic, > removes test vectors for bfin_crc that are no longer needed, and adds > unkeyed test vectors for crc32 and an extra unkeyed test vector for > crc32c. Adding the unkeyed test vectors also required a testmgr change > to allow a single hash algorithm to have both unkeyed and keyed tests, > without relying on having it work by accident. > > The new test vectors pass with the generic and x86 CRC implementations. > I haven't tested others yet; if any happen to be broken, they'll need to > be fixed. > > Eric Biggers (6): > crypto: crc32-generic - use unaligned access macros when needed > crypto: crc32c-generic - remove cra_alignmask > crypto: crc32-generic - remove __crc32_le() > crypto: testmgr - remove bfin_crc "hmac(crc32)" test vectors > crypto: testmgr - fix testing OPTIONAL_KEY hash algorithms > crypto: testmgr - add more unkeyed crc32 and crc32c test vectors > > crypto/crc32_generic.c | 15 ++ > crypto/crc32c_generic.c | 8 ++-- > crypto/tcrypt.c | 4 -- > crypto/testmgr.c| 56 +- > crypto/testmgr.h| 102 ++-- > 5 files changed, 66 insertions(+), 119 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: chtls - fix a missing-check bug
On Fri, May 18, 2018 at 02:55:35PM -0500, Wenwen Wang wrote: > In do_chtls_setsockopt(), the tls crypto info is first copied from the > poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the > 'version' of the crypto info is checked. If the version is not as expected, > i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that > the provided crypto info is not supported yet. Then, the 'cipher_type' > field of the 'tmp_crypto_info' is also checked to see if it is > TLS_CIPHER_AES_GCM_128. If it is, the whole struct of > tls12_crypto_info_aes_gcm_128 is copied from the pointer 'optval' and then > the function chtls_setkey() is invoked to set the key. > > Given that the 'optval' pointer resides in userspace, a malicious userspace > process can race to change the data pointed by 'optval' between the two > copies. For example, a user can provide a crypto info with TLS_1_2_VERSION > and TLS_CIPHER_AES_GCM_128. After the first copy, the user can modify the > 'version' and the 'cipher_type' fields to any versions and/or cipher types > that are not allowed. This way, the user can bypass the checks, inject > bad data to the kernel, cause chtls_setkey() to set a wrong key or other > issues. > > This patch reuses the data copied in the first try so as to ensure these > checks will not be bypassed. > > Signed-off-by: Wenwen Wang <wang6...@umn.edu> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: inside-secure - do not use memset on MMIO
On Thu, May 17, 2018 at 03:22:14PM +0200, Antoine Tenart wrote:
> This patch fixes the Inside Secure driver which uses a memtset() call to
> set an MMIO area from the cryptographic engine to 0. This is wrong as
> memset() isn't guaranteed to work on MMIO for many reasons. This led to
> kernel paging request panics in certain cases. Use memset_io() instead.
>
> Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto
> engine driver")
> Reported-by: Ofer Heifetz <of...@marvell.com>
> Signed-off-by: Antoine Tenart <antoine.ten...@bootlin.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 00/10] crypto: inside-secure - AEAD support
On Mon, May 14, 2018 at 03:10:54PM +0200, Antoine Tenart wrote: > This series brings AEAD algorithms to the Inside Secure SafeXcel driver. > The first 7 commits rework the driver to allow the future AEAD addition, > and then 3 commits add AEAD functions and 3 algorithms. > > This is based on top of v4.17-rc5. > > Thanks! > Antoine > > Since v1: > - Reworked the driver to remove VLA's and added a custom on-stack > request definition in the driver, to be used in the invalidation > process. (Patch 1/10 was replaced, patch 8/10 was reworked). > - Rebased on top of v4.17-rc5 (was -rc3). > > Antoine Tenart (10): > crypto: inside-secure - remove VLAs > crypto: inside-secure - rework cipher functions for future AEAD > support > crypto: inside-secure - rework the alg type settings in the context > crypto: inside-secure - make the context control size dynamic > crypto: inside-secure - make the key and context size computation > dynamic > crypto: inside-secure - fix the hash then encrypt/decrypt types > crypto: inside-secure - improve error reporting > crypto: inside-secure - authenc(hmac(sha256),cbc(aes)) support > crypto: inside-secure - authenc(hmac(sha224),cbc(aes)) support > crypto: inside-secure - authenc(hmac(sha1),cbc(aes)) support > > drivers/crypto/Kconfig| 1 + > drivers/crypto/inside-secure/safexcel.c | 32 + > drivers/crypto/inside-secure/safexcel.h | 44 +- > .../crypto/inside-secure/safexcel_cipher.c| 642 ++ > drivers/crypto/inside-secure/safexcel_hash.c | 23 +- > 5 files changed, 600 insertions(+), 142 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: chtls: generic handling of data and hdr
On Mon, May 14, 2018 at 04:41:38PM +0530, Atul Gupta wrote: > removed redundant check and made TLS PDU and header recv > handling common as received from HW. > Ensure that only tls header is read in cpl_rx_tls_cmp > read-ahead and skb is freed when entire data is processed. > > Signed-off-by: Atul Gupta <atul.gu...@chelsio.com> > Signed-off-by: Harsh Jain <ha...@chelsio.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: PBKDF2 support in the linux kernel
On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote: > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support in the > kernel? (https://tools.ietf.org/html/rfc2898#5.2) > We have hmac sha1 in the kernel, do we have plan to port/implement > corresponding PBKDF2 in the kernel too? The rule for adding crypto code to the kernel is simple, there must be an in-kernel user of the algorithm. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] Add support for MORUS AEAD algorithm
On Fri, May 11, 2018 at 02:19:08PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek <omosna...@gmail.com> > > This patchset adds the MORUS AEAD algorithm implementation to the Linux > Crypto API. > > MORUS [1] is a dedicated AEAD algorithm focused on SIMD instructions and > designed for high throughput both on modern processors and in hardware. It is > designed by Hongjun Wu and Tao Huang and has been submitted to the CAESAR > competiton [2], where it is currently one of the finalists [3]. MORUS uses > only logical bitwise operations and bitwise rotations as primitives. > > MORUS has two variants: > * MORUS-640 operating on 128-bit blocks and accepting a 128-bit key. > * MORUS-1280 operating on 256-bit blocks and accepting a 128- or 256-bit key. > Both variants accept a 128-bit IV and produce an up to 128-bit tag. > > The patchset contains four patches, adding: > * generic implementations > * test vectors to testmgr > * common glue code for x86_64 optimizations > * x86_64 SSE2/AVX2 optimized implementations > > Since there are no official test vectors currently available, the test > vectors in patch 2 were generated using a reference implementation from > public CAESAR benchmarks [4]. They should be replaced/complemented with > official test vectors if/when they become available. > > The implementations have been developed in cooperation with Milan Broz (the > maintainer of dm-crypt and cryptsetup) and there is a plan to use them for > authenticated disk encryption in cryptsetup. They are a result of my Master's > thesis at the Faculty of Informatics, Masaryk University, Brno [5]. > > [1] https://competitions.cr.yp.to/round3/morusv2.pdf > [2] https://competitions.cr.yp.to/caesar-call.html > [3] https://competitions.cr.yp.to/caesar-submissions.html > [4] https://bench.cr.yp.to/ebaead.html > [5] https://is.muni.cz/th/409879/fi_m/?lang=en > > Ondrej Mosnacek (4): > crypto: Add generic MORUS AEAD implementations > crypto: testmgr - Add test vectors for MORUS > crypto: Add common SIMD glue code for MORUS > crypto: x86 - Add optimized MORUS implementations All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] Add support for AEGIS AEAD algorithm
On Fri, May 11, 2018 at 02:12:48PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek <omosna...@gmail.com> > > This patchset adds the AEGIS AEAD algorithm implementation to the Linux > Crypto API. > > AEGIS [1] is a dedicated AEAD algorithm based on the AES round function and > designed for high throughput both on modern processors and in hardware. It is > designed by Hongjun Wu and Bart Preneel and has been submitted to the CAESAR > competiton [2], where it is currently one of the finalists [3]. > > AEGIS uses the AES round function and logical bitwise operations as > primitives. It achieves extremely good performance in software (on platforms > with HW-accelerated AES round function) and in hardware. > > AEGIS has three variants: > * AEGIS-128 operating on 128-bit blocks and accepting a 128-bit IV and key. > * AEGIS-128L operating on pairs of 128-bit blocks and accepting a 128-bit IV > and key. > * AEGIS-256 operating on 128-bit blocks and accepting a 256-bit IV and key. > All three variants produce an up to 128-bit tag. > > The patchset contains three patches, adding: > * generic implementations > * test vectors to testmgr > * x86_64 AES-NI+SSE2 optimized implementations > > Since there are no official test vectors currently available, the test > vectors in patch 2 were generated using a reference implementation from > public CAESAR benchmarks [4]. They should be replaced/complemented with > official test vectors if/when they become available. > > The implementations have been developed in cooperation with Milan Broz (the > maintainer of dm-crypt and cryptsetup) and there is a plan to use them for > authenticated disk encryption in cryptsetup. They are a result of my Master's > thesis at the Faculty of Informatics, Masaryk University, Brno [5]. > > [1] https://competitions.cr.yp.to/round3/aegisv11.pdf > [2] https://competitions.cr.yp.to/caesar-call.html > [3] https://competitions.cr.yp.to/caesar-submissions.html > [4] https://bench.cr.yp.to/ebaead.html > [5] https://is.muni.cz/th/409879/fi_m/?lang=en > > Ondrej Mosnacek (3): > crypto: Add generic AEGIS AEAD implementations > crypto: testmgr - Add test vectors for AEGIS > crypto: x86 - Add optimized AEGIS implementations All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: reorder paes test lexicographically
On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote:
> Due to a snafu "paes" testmgr tests were not ordered
> lexicographically, which led to boot time warnings.
> Reorder the tests as needed.
>
> Fixes: a794d8d ("crypto: ccree - enable support for hardware keys")
> Reported-by: Abdul Haleem <abdha...@linux.vnet.ibm.com>
> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"
On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: chelsio: request to HW should wrap
On Thu, May 10, 2018 at 10:14:42AM +0530, Atul Gupta wrote: > -Tx request and data is copied to HW Q in 64B desc, check for > end of queue and adjust the current position to start from > beginning before passing the additional request info. > -key context copy should check key length only > -Few reverse christmas tree correction > > Signed-off-by: Atul Gupta <atul.gu...@chelsio.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] hwrng: n2: fix spelling mistake: "restesting" -> "retesting"
Colin King <colin.k...@canonical.com> wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fix to spelling mistake in dev_err error message > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines
On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote:
> In the vmx AES init routines we do a printk(KERN_INFO ...) to report
> the fallback implementation we're using.
>
> However with a slow console this can significantly affect the speed of
> crypto operations. Using 'cryptsetup benchmark' the removal of the
> printk() leads to a ~5x speedup for aes-cbc decryption.
>
> So remove them.
>
> Fixes: 8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
> Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
> Fixes: 4f7f60d312b3 ("crypto: vmx - Adding CTR routines for VMX module")
> Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
> ---
> drivers/crypto/vmx/aes.c | 2 --
> drivers/crypto/vmx/aes_cbc.c | 3 ---
> drivers/crypto/vmx/aes_ctr.c | 2 --
> drivers/crypto/vmx/ghash.c | 2 --
> 4 files changed, 9 deletions(-)
Patch applied. Thanks.
> If this is the wrong fix please let me know, I'm not a crypto expert.
>
> What we see is 'cryptsetup benchmark' causing thousands of these printks() to
> happen. The call trace is something like:
>
> [c01e47867a60] [c09cf6b4] p8_aes_cbc_init+0x74/0xf0
> [c01e47867ae0] [c0551a80] __crypto_alloc_tfm+0x1d0/0x2c0
> [c01e47867b20] [c055aea4] crypto_skcipher_init_tfm+0x124/0x280
> [c01e47867b60] [c055138c] crypto_create_tfm+0x9c/0x1a0
> [c01e47867ba0] [c0552220] crypto_alloc_tfm+0xa0/0x140
> [c01e47867c00] [c055b168] crypto_alloc_skcipher+0x48/0x70
> [c01e47867c40] [c057af28] skcipher_bind+0x38/0x50
> [c01e47867c80] [c057a07c] alg_bind+0xbc/0x220
> [c01e47867d10] [c0a016a0] __sys_bind+0x90/0x100
> [c01e47867df0] [c0a01750] sys_bind+0x40/0x60
> [c01e47867e30] [c000b320] system_call+0x58/0x6c
>
>
> Is it normal for init to be called on every system call?
This is the tfm init function, so yes it is called every time
you allocate a tfm.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH resend 00/10] crypto: arm64 - play nice with CONFIG_PREEMPT
On Mon, Apr 30, 2018 at 06:18:20PM +0200, Ard Biesheuvel wrote: > Hello Herbert, > > These are the patches that depend on the arm64/assembler.h patches that > inadvertently got pulled into the cryptodev tree and reverted shortly > after. Those have now been merged into Linus's tree, and so the > remaining changes can be applied as well. Please apply. > > Ard Biesheuvel (10): > crypto: arm64/sha1-ce - yield NEON after every block of input > crypto: arm64/sha2-ce - yield NEON after every block of input > crypto: arm64/aes-ccm - yield NEON after every block of input > crypto: arm64/aes-blk - yield NEON after every block of input > crypto: arm64/aes-bs - yield NEON after every block of input > crypto: arm64/aes-ghash - yield NEON after every block of input > crypto: arm64/crc32-ce - yield NEON after every block of input > crypto: arm64/crct10dif-ce - yield NEON after every block of input > crypto: arm64/sha3-ce - yield NEON after every block of input > crypto: arm64/sha512-ce - yield NEON after every block of input > > arch/arm64/crypto/aes-ce-ccm-core.S | 150 + > arch/arm64/crypto/aes-ce.S| 15 +- > arch/arm64/crypto/aes-modes.S | 331 > arch/arm64/crypto/aes-neonbs-core.S | 305 ++ > arch/arm64/crypto/crc32-ce-core.S | 40 ++- > arch/arm64/crypto/crct10dif-ce-core.S | 32 +- > arch/arm64/crypto/ghash-ce-core.S | 113 +-- > arch/arm64/crypto/ghash-ce-glue.c | 28 +- > arch/arm64/crypto/sha1-ce-core.S | 42 ++- > arch/arm64/crypto/sha2-ce-core.S | 37 ++- > arch/arm64/crypto/sha3-ce-core.S | 77 +++-- > arch/arm64/crypto/sha512-ce-core.S| 27 +- > 12 files changed, 762 insertions(+), 435 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage
On Wed, May 02, 2018 at 12:25:33AM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva <gust...@embeddedor.com> > Signed-off-by: Atul Gupta <atul.gu...@chelsio.com> These patches really should be sent to netdev as well and I'd like to see some acks from there. Also please add a cover email for the series. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote: > > Are you suggesting that the SIMD wrapper, will do what is currently being > done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) > i.e dispatching the job to the inner algorithm? > > I have got rid of the mcryptd layer( have an inner layer, outer SIMD layer, > handled the pointers and completions accordingly), but still facing some > issues after removing the per cpu mcryptd_cpu_queue. Why don't you post what you've got and we can work it out together? Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: DMA map buffer allocated in ahash_request_ctx
On Wed, May 09, 2018 at 04:13:12PM +0300, Gilad Ben-Yossef wrote: > On Wed, May 9, 2018 at 3:12 PM, Harsh Jain <harshjain.p...@gmail.com> wrote: > > Hi Herbert, > > > > Can we use buffer defined in ahash request context(private space for > > each request) to DMA map it to H/W.? > > Not Herbert but... the ccree driver is doing just and Herbert > specifically indicated ahash request contexts are not allowed to be > allocated from stack (I asked) so it should be OK. That's right. For async algorithms the request must come from kmalloc memory. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Tue, May 01, 2018 at 10:39:15PM +, Dey, Megha wrote: > > crypto/simd.c provides a simd_skcipher_create_compat. I have used the same > template to introduce simd_ahash_create_compat > which would wrap around the inner hash algorithm. > > Hence we would still register 2 algs, outer and inner. Right. > Currently we have outer_alg -> mcryptd alg -> inner_alg > > Mcryptd is mainly providing the following: > 1. Ensuring the lanes(8 in case of AVX2) are full before dispatching to the > lower inner algorithm. This is obviously why we would expect better > performance for multi-buffer as opposed to the present single-buffer > algorithms. > 2. If there no new incoming jobs, issue a flush. > 3. A glue layer which sends the correct pointers and completions. > > If we get rid of mcryptd, these functions needs to be done by someone. Since > all multi-buffer algorithms would require this tasks, where do you suggest > these helpers live, if not the current mcryptd.c? That's the issue. I don't think mcryptd is doing any of these claimed functions except for hosting the flush helper which could really live anywhere. All these functions are actually being carried out in the inner algorithm already. > I am not sure if you are suggesting that we need to get rid of the mcryptd > work queue itself. In that case, we would need to execute in the context of > the job requesting the crypto transformation. Which is fine as long as you can disable the FPU. If not the simd wrapper will defer the job to kthread context as required. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ghash-clmulni: fix spelling mistake: "acclerated" -> "accelerated"
On Fri, Apr 27, 2018 at 07:08:05PM +0100, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fix to spelling mistake in module description text > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: tcrypt: Remove VLA usage
On Thu, Apr 26, 2018 at 07:57:28PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > allocates the return code buffers before starting jiffie timers, rather > than using stack space for the array. Additionally cleans up some exit > paths and make sure that the num_mb module_param() is used only once > per execution to avoid possible races in the value changing. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Kees Cook <keesc...@chromium.org> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam - fix size of RSA prime factor q
On Fri, Apr 27, 2018 at 11:40:11AM +0300, Horia Geantă wrote:
> Fix a typo where size of RSA prime factor q is using the size of
> prime factor p.
>
> Cc: <sta...@vger.kernel.org> # 4.13+
> Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
> Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
> Reported-by: David Binderman <dcb...@hotmail.com>
> Signed-off-by: Horia Geantă <horia.gea...@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] Fix stm32-rng for default state and suspend
On Mon, Apr 23, 2018 at 05:04:24PM +0200, Lionel Debieve wrote: > This series are fixing the default build state for stm32-rng that > activate the driver with arm multi_v7_defconfig. > Second patch is fixing the power suspend/resume behavior which was > not working. > > Lionel Debieve (2): > hwrng: stm32 - define default state for rng driver > hwrng: stm32-rng: Fix pm_suspend issue > > drivers/char/hw_random/Kconfig | 1 + > drivers/char/hw_random/stm32-rng.c | 9 +++-- > 2 files changed, 8 insertions(+), 2 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: implement SM4 for arm64 using special instructions
On Wed, Apr 25, 2018 at 02:20:44PM +0200, Ard Biesheuvel wrote: > Patch #1 makes some preparatory changes so the C routines can be used as > a fallback by other drivers. > > Patch #2 implements the SM4 core cipher using the special instructions > introduced as an optional extension by revision 8.2 of the ARM architecture. > > Note that this does not implement cipher+chaining mode combinations as we > do for AES. This can be added later if desiresd. > > Ard Biesheuvel (2): > crypto: sm4 - export encrypt/decrypt routines to other drivers > crypto: arm64 - add support for SM4 encryption using special > instructions > > arch/arm64/crypto/Kconfig | 6 ++ > arch/arm64/crypto/Makefile | 3 + > arch/arm64/crypto/sm4-ce-core.S | 36 ++ > arch/arm64/crypto/sm4-ce-glue.c | 73 > crypto/sm4_generic.c| 10 +-- > include/crypto/sm4.h| 3 + > 6 files changed, 127 insertions(+), 4 deletions(-) > create mode 100644 arch/arm64/crypto/sm4-ce-core.S > create mode 100644 arch/arm64/crypto/sm4-ce-glue.c All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] cleanup and hardware keys
On Mon, Apr 23, 2018 at 08:25:13AM +0100, Gilad Ben-Yossef wrote: > Small cleanup and add support for CryptoCell hardware keys. > > Changes from v1: > - The cleanup patch is new, as Herbert took the previous one :-) > - Hardware key API uses the "paes" designator to indicate a protected key, > same as s390, as per Herbert preference > - Avoid direct casting and reference of key material, as pointed out by > Herbert > > Gilad Ben-Yossef (2): > crypto: ccree: enable support for hardware keys > crypto: ccree: use proper printk format > > crypto/testmgr.c | 43 + > drivers/crypto/ccree/cc_cipher.c | 350 > ++- > drivers/crypto/ccree/cc_cipher.h | 30 +--- > drivers/crypto/ccree/cc_driver.c | 2 +- > 4 files changed, 362 insertions(+), 63 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 01/10] crypto: aead - allow to allocate AEAD requests on the stack
On Fri, May 04, 2018 at 09:18:41AM +0200, 'Antoine Tenart' wrote: > > In this driver we need to perform in certain cases an invalidation, > which is done thanks to invalidation requests. To do this we create > dummy requests, using SKCIPHER_REQUEST_ON_STACK and > AHASH_REQUEST_ON_STACK for ciphers and hashes. So when adding the AEAD > algs support, in patch 8/10, AEAD_REQUEST_ON_STACK is used for the same > reason. > > Should we allocate this in a different way? These are not uses intended for the ON_STACK macros. They were only ever meant for existing users of the synchonous crypto API. I would suggest either allocating a new request on the spot or if that is not convenient, pre-allocating it in the cra_init function. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 01/10] crypto: aead - allow to allocate AEAD requests on the stack
On Thu, May 03, 2018 at 02:23:30PM +0200, 'Antoine Tenart' wrote: > > I was expecting this question :) The thing is this define looks *a lot* > like the ones defined in other places in the crypto framework, such as > SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. Those haven't been > tackled down so far by the whole VLA removal so the idea was that the > same solution will apply to the 3 of them (and then I'm not really > adding a new one). Those constructs only exist for reasons of backwards compatibility. There is no such reason for AEAD. So why do you need this? Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v1 1/7] crypto: crypto4xx - performance optimizations
Christian Lamparter <chunk...@gmail.com> wrote: > This patch provides a cheap 2MiB/s+ (~ 6%) performance > improvement over the current code. This is because the > compiler can now optimize several endian swap memcpy. > > Signed-off-by: Christian Lamparter <chunk...@gmail.com> All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH v2] crypto: cavium: zip: Remove unnecessary parentheses
On Thu, Apr 19, 2018 at 09:19:43PM +0530, Varsha Rao wrote: > This patch fixes the clang warning of extraneous parentheses, with the > following coccinelle script. > > @@ > identifier i; > constant c; > expression e; > @@ > ( > !((e)) > | > -(( > \(i == c\|i != c\|i <= c\|i < c\|i >= c\|i > c\) > -)) > ) > > Signed-off-by: Varsha Rao <rvarsha...@gmail.com> > --- > Changes in v2: > - Modified coccinelle script > > drivers/crypto/cavium/zip/zip_regs.h | 42 > ++-- > 1 file changed, 21 insertions(+), 21 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 06/61] crypto: simplify getting .drvdata
On Thu, Apr 19, 2018 at 04:05:36PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > --- > > Build tested only. buildbot is happy. Please apply individually. > > drivers/crypto/exynos-rng.c | 6 ++ > drivers/crypto/picoxcell_crypto.c | 6 ++ > 2 files changed, 4 insertions(+), 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: omap-sham: fix memleak
On Tue, Apr 17, 2018 at 02:53:13PM -0500, Bin Liu wrote:
> Fixes: 8043bb1ae03cb ("crypto: omap-sham - convert driver logic to use sgs
> for data xmit")
>
> The memory pages freed in omap_sham_finish_req() were less than those
> allocated in omap_sham_copy_sgs().
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Bin Liu <b-...@ti.com>
> ---
> drivers/crypto/omap-sham.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Crypto Fixes for 4.17
Hi Linus: This push fixes the following issues: - Crypto API regression that may cause sporadic alloc failures. - Double-free bug in drbg. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Eric Biggers (1): crypto: api - fix finding algorithm currently being tested Stephan Mueller (1): crypto: drbg - set freed buffers to NULL crypto/api.c | 11 --- crypto/drbg.c |2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Wed, Apr 25, 2018 at 01:14:26AM +, Dey, Megha wrote: > > Is there any existing implementation of async crypto algorithm that uses the > above approach? The ones I could find are either sync, have an outer and > inner algorithm or use cryptd. > > I tried removing the mcryptd layer and the outer algorithm and some plumbing > to pass the correct structures, but see crashes.(obviously some errors in the > plumbing) OK, you can't just remove it because the inner algorithm requires kernel_fpu_begin/kernel_fpu_end. So we do need two layers but I don't think we need cryptd or mcryptd. The existing simd wrapper should work just fine on the inner algorithm, provided that we add hash support to it. > I am not sure if we remove mcryptd, how would we queue work, flush partially > completed jobs or call completions (currently done by mcryptd) if we simply > call the inner algorithm. I don't think mcryptd is providing any real facility to the flushing apart from a helper. That same helper can live anywhere. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register
Hi Fabio:
On Fri, Apr 20, 2018 at 03:21:47PM -0300, Fabio Estevam wrote:
>
> It is not a regression.
>
> We haven't seen this problem before because dtsi files passed the
> 'fsl,sec-era' property.
>
> Since 4.17-rc1, imx7 supports CAAM:
> 0eeabcad7da5 ("ARM: dts: imx7s: add CAAM device node")
>
> ,but it does not pass the 'fsl,sec-era' property leading to the following
> error:
> caam 3090.caam: device ID = 0x0a160300 (Era -524)
>
> Documentation/devicetree/bindings/crypto/fsl-sec4.txt states that
> 'fsl,sec-era' property is optional, so 0eeabcad7da5 is not incorrect
> by not passing it.
>
> As we can retrieve the era information by reading the CAAM registers
> we can fix the problem on imx7 running 4.17-rc with this patch.
As this is a new device support issue I'd prefer to delay this
until the next merge window.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register
On Fri, Apr 20, 2018 at 02:11:07PM -0300, Fabio Estevam wrote: > > Would it be possible to consider applying this one for 4.17-rc? > > Without this patch we get incorrect CAAM IP block version (era) on > i.MX7 on 4.17-rc1: > > caam 3090.caam: device ID = 0x0a160300 (Era -524) Is this a regression or a preexisting bug? Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] hwrng: via-rng - support new Centaur CPU
On Fri, Apr 13, 2018 at 03:03:03PM +0800, David Wang wrote: > New Centaur CPU(Family > 6) supprt Random Number Generator, but can't > support MSR_VIA_RNG. Just like VIA Nano. > > Signed-off-by: David Wang <davidw...@zhaoxin.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: api - fix finding algorithm currently being tested
On Mon, Apr 16, 2018 at 04:59:13PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebigg...@google.com>
>
> Commit eb02c38f0197 ("crypto: api - Keep failed instances alive") is
> making allocating crypto transforms sometimes fail with ELIBBAD, when
> multiple processes try to access encrypted files with fscrypt for the
> first time since boot. The problem is that the "request larval" for the
> algorithm is being mistaken for an algorithm which failed its tests.
>
> Fix it by only returning ELIBBAD for "non-larval" algorithms. Also
> don't leak a reference to the algorithm.
>
> Fixes: eb02c38f0197 ("crypto: api - Keep failed instances alive")
> Signed-off-by: Eric Biggers <ebigg...@google.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: caam: - Use kmemdup() function
On Mon, Apr 16, 2018 at 01:05:01PM -0300, Fabio Estevam wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > Use kmemdup() rather than duplicating its implementation. > > By usign kmemdup() we can also get rid of the 'val' variable. > > Detected with Coccinelle script. > > Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam - strip input zeros from RSA input buffer
On Mon, Apr 16, 2018 at 12:34:45PM +0300, Horia Geantă wrote:
> Sometimes the provided RSA input buffer provided is not stripped
> of leading zeros. This could cause its size to be bigger than that
> of the modulus, making the HW complain:
>
> caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
> Protocol Size Error - A protocol has seen an error in size. When
> running RSA, pdb size N < (size of F) when no formatting is used; or
> pdb size N < (F + 11) when formatting is used.
>
> Fix the problem by stripping off the leading zero from input data
> before feeding it to the CAAM accelerator.
>
> Fixes: 8c419778ab57e ("crypto: caam - add support for RSA algorithm")
> Cc: <sta...@vger.kernel.org> # 4.8+
> Reported-by: Martin Townsend <mtownsend1...@gmail.com>
> Link:
> https://lkml.kernel.org/r/cabatt_ytyoryktapcb4izhnanekkgfi9xaqmjhi_n-8ywoc...@mail.gmail.com
> Signed-off-by: Horia Geantă <horia.gea...@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: drbg - set freed buffers to NULL
On Thu, Apr 12, 2018 at 08:40:55AM +0200, Stephan Müller wrote:
> Add the Fixes, CC stable tags.
>
> ---8<---
>
> During freeing of the internal buffers used by the DRBG, set the pointer
> to NULL. It is possible that the context with the freed buffers is
> reused. In case of an error during initialization where the pointers
> do not yet point to allocated memory, the NULL value prevents a double
> free.
>
> Cc: sta...@vger.kernel.org
> Fixes: 3cfc3b9721123 ("crypto: drbg - use aligned buffers")
> Signed-off-by: Stephan Mueller <smuel...@chronox.de>
> Reported-by: syzbot+75397ee3df5c70164...@syzkaller.appspotmail.com
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: rsa - Remove unneeded error assignment
On Wed, Apr 11, 2018 at 06:37:17PM -0300, Fabio Estevam wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > There is no need to assign an error value to 'ret' prior > to calling mpi_read_raw_from_sgl() because in the case > of error the 'ret' variable will be assigned to the error > code inside the if block. > > In the case of non failure, 'ret' will be overwritten > immediately after, so remove the unneeded assignment. > > Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: testmgr: Allow different compression results
On Thu, Apr 19, 2018 at 01:58:40PM +0200, Jan Glauber wrote:
>
> Nice idea. Would a crypto_alloc_cipher("deflate", ...) pick the generic
> implementation or how can we select it?
For our ciphers we generally use the -generic suffix in the driver
name. The compression algorithms seem to be all over the place on
this so we should fix them all to use the -generic suffix and then
we can simply append the -generic suffix here before allocating it.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH][next] crypto: chtls: don't leak information from the stack to userspace
On Thu, Apr 05, 2018 at 05:44:03PM +0100, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> The structure crypto_info contains fields that are not initialized and
> only .version is set. The copy_to_user call is hence leaking information
> from the stack to userspace which must be avoided. Fix this by zero'ing
> all the unused fields.
>
> Detected by CoverityScan, CID#1467421 ("Uninitialized scalar variable")
>
> Fixes: a08943947873 ("crypto: chtls - Register chtls with net tls")
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto : chtls_cm - Fix potential NULL pointer dereferences
On Tue, Apr 03, 2018 at 03:09:12PM -0500, Gustavo A. R. Silva wrote:
> Add null checks on lookup_tid() return value in order to prevent
> null pointer dereferences.
>
> Addresses-Coverity-ID: 1467422 ("Dereference null return value")
> Addresses-Coverity-ID: 1467443 ("Dereference null return value")
> Addresses-Coverity-ID: 1467445 ("Dereference null return value")
> Addresses-Coverity-ID: 1467449 ("Dereference null return value")
> Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
> Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH][next] crypto: chtls: remove redundant assignment to cdev->ports
On Fri, Apr 06, 2018 at 05:58:47PM +0100, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> There is a double assignment to cdev->ports, the first is redundant
> as it is over-written so remove it.
>
> Detected by CoverityScan, CID#1467432 ("Unused value")
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 1/2] crypto: caam - staticize caam_get_era()
On Wed, Apr 11, 2018 at 09:45:19AM -0300, Fabio Estevam wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > caam_get_era() is only used locally, so do not export this function > and make it static instead. > > Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> > Reviewed-by: Horia Geantă <horia.gea...@nxp.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: testmgr: Allow different compression results
On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote: > From: Mahipal Challa <mcha...@cavium.com> > > The following error is triggered by the ThunderX ZIP driver > if the testmanager is enabled: > > [ 199.069437] ThunderX-ZIP :03:00.0: Found ZIP device 0 177d:a01a on > Node 0 > [ 199.073573] alg: comp: Compression test 1 failed for deflate-generic: > output len = 37 > > The reason for this error is the verification of the compression > results. Verifying the compression result only works if all > algorithm parameters are identical, in this case to the software > implementation. > > Different compression engines like the ThunderX ZIP coprocessor > might yield different compression results by tuning the > algorithm parameters. In our case the compressed result is > shorter than the test vector. > > We should not forbid different compression results but only > check that compression -> decompression yields the same > result. This is done already in the acomp test. Do something > similar for test_comp(). > > Signed-off-by: Mahipal Challa <mcha...@cavium.com> > Signed-off-by: Balakrishna Bhamidipati <bbhamidip...@cavium.com> > [jglau...@cavium.com: removed unrelated printk changes, rewrote commit msg, > fixed whitespace and unneeded initialization] > Signed-off-by: Jan Glauber <jglau...@cavium.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] crypto: removing various VLAs
On Mon, Apr 09, 2018 at 03:54:45PM +0200, Salvatore Mesoraca wrote: > v2: > As suggested by Herbert Xu, the blocksize and alignmask checks > have been moved to crypto_check_alg. > So, now, all the other separate checks are not necessary. > Also, the defines have been moved to include/crypto/algapi.h. > > v1: > As suggested by Laura Abbott[1], I'm resending my patch with > MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they > can be used in other places. > I took this opportunity to deal with some other VLAs not > handled in the old patch. > > [1] http://lkml.kernel.org/r/4e536889-439a-49e6-dd95-2d4286913...@redhat.com > > Salvatore Mesoraca (2): > crypto: api - laying defines and checks for statically allocated > buffers > crypto: remove several VLAs > > crypto/algapi.c | 10 ++ > crypto/cfb.c| 7 +++ > crypto/cipher.c | 3 ++- > crypto/ctr.c| 4 ++-- > crypto/cts.c| 5 +++-- > crypto/pcbc.c | 5 +++-- > include/crypto/algapi.h | 8 > 7 files changed, 31 insertions(+), 11 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register
On Wed, Apr 11, 2018 at 09:45:20AM -0300, Fabio Estevam wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era' property is not passed in the device > tree. > > This function is based on the U-Boot implementation from > drivers/crypto/fsl/sec.c > > Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/5] ThunderX ZIP driver bug fixes
On Mon, Apr 09, 2018 at 05:45:49PM +0200, Jan Glauber wrote: > Some bug fixes for this driver after it stopped working with virtual mapped > stacks. I think the first two patches qualify for stable. > > Jan Glauber (5): > crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK > crypto: thunderx_zip: Limit result reading attempts > crypto: thunderx_zip: Prevent division by zero > crypto: thunderx_zip: Fix statistics pending request value > crypto: thunderx_zip: Fix smp_processor_id() warnings > > drivers/crypto/cavium/zip/common.h | 21 + > drivers/crypto/cavium/zip/zip_crypto.c | 22 ++ > drivers/crypto/cavium/zip/zip_deflate.c | 4 ++-- > drivers/crypto/cavium/zip/zip_device.c | 4 ++-- > drivers/crypto/cavium/zip/zip_inflate.c | 4 ++-- > drivers/crypto/cavium/zip/zip_main.c| 24 +++- > drivers/crypto/cavium/zip/zip_main.h| 1 - > 7 files changed, 52 insertions(+), 28 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 1/2] crypto: authenc - don't leak pointers to authenc keys
On Tue, Apr 03, 2018 at 09:39:00AM +0300, Tudor Ambarus wrote: > In crypto_authenc_setkey we save pointers to the authenc keys in > a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH] crypto: Add zstd support
On Fri, Mar 30, 2018 at 12:14:53PM -0700, Nick Terrell wrote: > Adds zstd support to crypto and scompress. Only supports the default > level. > > Previously we held off on this patch, since there weren't any users. > Now zram is ready for zstd support, but depends on CONFIG_CRYPTO_ZSTD, > which isn't defined until this patch is in. I also see a patch adding > zstd to pstore [0], which depends on crypto zstd. > > [0] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com > > Signed-off-by: Nick Terrell <terre...@fb.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 2/2] crypto: authencesn - don't leak pointers to authenc keys
On Tue, Apr 03, 2018 at 09:39:01AM +0300, Tudor Ambarus wrote: > In crypto_authenc_esn_setkey we save pointers to the authenc keys > in a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto/ecc: Actually remove stack VLA usage
On Fri, Mar 30, 2018 at 09:55:44AM -0700, Kees Cook wrote:
> On the quest to remove all VLAs from the kernel[1], this avoids VLAs
> by just using the maximum allocation size (4 bytes) for stack arrays.
> All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just
> make it 4 bytes all the time. Initialization routines are adjusted to
> check that ndigits does not end up larger than the arrays.
>
> This includes a removal of the earlier attempt at this fix from
> commit a963834b4742 ("crypto/ecc: Remove stack VLA usage")
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: caam - IV-related fixes
On Wed, Mar 28, 2018 at 03:39:16PM +0300, Horia Geantă wrote: > This patch set fixes several issues related to IV handling: > -in some cases IV direction is incorrect > -IVs need to be DMA mapped (when they are not provided directly > as "immediate" values in the descriptors); however, crypto API does not > guarantee the IV buffers to be DMAable > -in-place ablkcipher decryption needs special handling since ciphertext > will be overwritten by the time we want to update the IV with the last > ciphertext block > > Horia Geantă (3): > crypto: caam - fix DMA mapping dir for generated IV > crypto: caam - fix IV DMA mapping and updating > crypto: caam/qi - fix IV DMA mapping and updating > > drivers/crypto/caam/caamalg.c| 231 > +-- > drivers/crypto/caam/caamalg_qi.c | 227 +++--- > 2 files changed, 219 insertions(+), 239 deletions(-) All applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: testmgr: Allow different compression results
On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote:
>
> @@ -1362,7 +1373,17 @@ static int test_comp(struct crypto_comp *tfm,
> goto out;
> }
>
> - if (dlen != ctemplate[i].outlen) {
> + ilen = dlen;
> + dlen = COMP_BUF_SIZE;
> + ret = crypto_comp_decompress(tfm, output,
> + ilen, decomp_output, );
> + if (ret) {
> + pr_err("alg: comp: compression failed: decompress: on
> test %d for %s failed: ret=%d\n",
> +i + 1, algo, -ret);
> + goto out;
> + }
> +
> + if (dlen != ctemplate[i].inlen) {
> printk(KERN_ERR "alg: comp: Compression test %d "
> "failed for %s: output len = %d\n", i + 1, algo,
> dlen);
Your patch is fine as it is.
But I just thought I'd mention that if anyone wants to we should
really change this to use a different tfm, e.g., always use the
generic algorithm to perform the decompression. This way if there
were multiple implementations we can at least test them against
the generic one.
Otherwise you could end up with a buggy implementation that works
against itself but still generates incorrect output.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Mon, Apr 09, 2018 at 11:42:31AM +0300, Gilad Ben-Yossef wrote: > > Please look again. The stub version of cc_is_hw_key() doing that is being > replaced in this patch. The point is that the existing mechanism was unused before and this is new code. So you can't really point to the stubbed-out function as a precedent. > The s390 key and the cryptocell keys are not the same: > > Their is, I believe, is an AES key encrypted by some internal key/algorithm. > > The cryptocell "key" is a token, which is internally comprised of one > or two indexes, referencing slots in the internal memory in the > hardware, and a key size, that describe the size of the key. > > I thought it would be confusing to use "paes" to describe both, since > they are not interchangeable. > You would not be able to feed an paes key that works with the s390 > version to cryptocell and vice verse and get it work. Thanks for the info. > Having said, if you prefer to have "paes" simply designate > "implementation specific token for an AES key" I'm perfectly fine with > that. Well by definition none of these hardware keys will be compatible with each other so I don't really see the point of using individual algorithm names such as paes or haes. This would make sense only if they were somehow compatible with each other. So instead of using algorithm names, you really want refer to the specific driver name, which means that they can all use the same algorithm name. > > As to your patch specifically, there is one issue where you're > > directly dereferencing the key as a struct. This is a no-no because > > the key may have come from user-space. You must treat it as a > > binary blob. The s390 code seems to do this correctly. > > As noted above, the haes "key" is really a token encoding 3 different > pieces of information: My point is that you should not just cast it but instead do a copy to properly aligned kernel memory. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Thu, Apr 19, 2018 at 12:54:16AM +, Dey, Megha wrote: > > Yeah I think I misunderstood. I think what you mean is to remove mcryptd.c > completely and avoid the extra layer of indirection to call the underlying > algorithm, instead call it directly, correct? > > So currently we have 3 algorithms registered for every multibuffer algorithm: > name : __sha1-mb > driver : mcryptd(__intel_sha1-mb) > > name : sha1 > driver : sha1_mb > > name : __sha1-mb > driver : __intel_sha1-mb > > If we remove mcryptd, then we will have just the 2? It should be down to just one, i.e., the current inner algorithm. It's doing all the scheduling work already so I don't really see why it needs the wrappers around it. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support
On Tue, Apr 17, 2018 at 06:40:17PM +, Dey, Megha wrote: > > > >-Original Message----- > >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > >Sent: Friday, March 16, 2018 7:54 AM > >To: Dey, Megha <megha@intel.com> > >Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; > >da...@davemloft.net > >Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure > >support > > > >I have taken a deeper look and I'm even more convinced now that mcryptd is > >simply not needed in your current model. > > > >The only reason you would need mcryptd is if you need to limit the rate of > >requests going into the underlying mb algorithm. > > > >However, it doesn't do that all. Even though it seems to have a batch size > >of > >10, but because it immediately reschedules itself after the batch runs out, > >it's essentially just dumping all requests at the underlying algorithm as > >fast > >as they're coming in. The underlying algorithm doesn't have need throttling > >anyway because it'll do the work when the queue is full synchronously. > > > >So why not just get rid of mcryptd completely and expose the underlying > >algorithm as a proper async skcipher/hash? > > Hi Herbert, > > Most part of the cryptd.c and mcryptd.c are similar, except the logic used to > flush out partially completed jobs > in the case of multibuffer algorithms. > > I think I will try to merge the cryptd and mcryptd adding necessary quirks > for multibuffer where needed. I think you didn't quite get my point. From what I'm seeing you don't need either cryptd or mcryptd. You just need to expose the underlying mb algorithm directly. So I'm not sure what we would gain from merging cryptd and mcryptd. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3/6] crypto: api - avoid VLA use
On Sun, Apr 08, 2018 at 11:07:12AM +0200, Salvatore Mesoraca wrote:
>
> > This check should be done when the algorithm is registered. Perhaps
> > crypto_check_alg.
>
> Please correct me if I'm wrong:
> isn't crypto_check_alg invoked also during hashing algorithm registration?
> In this patch-set I'm dealing only with ciphers, because the maximum
> block size (16)
> is relatively small and it's also the most common block size with
> ciphers (maybe I should
> have explicitly referenced ciphers in the macro names, my bad).
> I don't think that it would be OK to use a similar approach for hashes
> too, because some
> of them have block size >= 1024 bytes.
Yes we want to make it for ciphers only even if we move it to
crypto_check_alg.
For a legacy type like cipher cou can do it by
if (!alg->cra_type && (alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
CRYPTO_ALG_TYPE_CIPHER)
do_cipher_specific_check();
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/6] crypto: ctr - avoid VLA use
On Sun, Apr 08, 2018 at 10:58:48AM +0200, Salvatore Mesoraca wrote: > > Fair enough. > After removing the individual checks the modification to the single files > will be just a couple of lines, is it OK for you if I collapse all of them in > just a single commit? Sure. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/6] crypto: ctr - avoid VLA use
On Sat, Apr 07, 2018 at 08:38:19PM +0200, Salvatore Mesoraca wrote: > > @@ -206,6 +207,14 @@ static struct crypto_instance *crypto_ctr_alloc(struct > rtattr **tb) > if (alg->cra_blocksize < 4) > goto out_put_alg; > > + /* Block size must be <= MAX_BLOCKSIZE. */ > + if (alg->cra_blocksize > MAX_BLOCKSIZE) > + goto out_put_alg; > + > + /* Alignmask must be <= MAX_ALIGNMASK. */ > + if (alg->cra_alignmask > MAX_ALIGNMASK) > + goto out_put_alg; > + Since you're also adding a check to cipher algorithms in general, none of these individual checks are needed anymore. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 3/6] crypto: api - avoid VLA use
On Sat, Apr 07, 2018 at 08:38:20PM +0200, Salvatore Mesoraca wrote:
>
> int crypto_init_cipher_ops(struct crypto_tfm *tfm)
> {
> + const unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
> + const unsigned int size = crypto_tfm_alg_blocksize(tfm);
> struct cipher_tfm *ops = >crt_cipher;
> struct cipher_alg *cipher = >__crt_alg->cra_cipher;
>
> + if (size > MAX_BLOCKSIZE || alignmask > MAX_ALIGNMASK)
> + return -EINVAL;
> +
This check should be done when the algorithm is registered. Perhaps
crypto_check_alg.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/6] crypto: api - laying macros for statically allocated buffers
On Sat, Apr 07, 2018 at 08:38:18PM +0200, Salvatore Mesoraca wrote: > Creating 2 new compile-time constants for internal use, > in preparation for the removal of VLAs[1] from crypto code. > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding hw require 16 bytes > alignment for the block buffer. > > [1] > http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Salvatore Mesoraca <s.mesorac...@gmail.com> > --- > crypto/internal.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/crypto/internal.h b/crypto/internal.h > index 9a3f399..89ae41e 100644 > --- a/crypto/internal.h > +++ b/crypto/internal.h > @@ -26,6 +26,14 @@ > #include > #include > > +/* > + * Maximum values for blocksize and alignmask, used to allocate > + * static buffers that are big enough for any combination of > + * ciphers and architectures. > + */ > +#define MAX_BLOCKSIZE16 > +#define MAX_ALIGNMASK15 No please don't put this here if you intend on using it everywhere. This file is reserved for truly internal bits. Perhaps include/crypto/algapi.h would be a better place. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Crypto Update for 4.17
RST flag crypto: speck - add support for the Speck block cipher crypto: speck - export common helpers crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS crypto: speck - add test vectors for Speck128-XTS crypto: speck - add test vectors for Speck64-XTS crypto: simd - allow registering multiple algorithms at once crypto: x86/glue_helper - add skcipher_walk functions crypto: x86/serpent-sse2 - remove LRW algorithm crypto: x86/serpent-sse2 - remove XTS algorithm crypto: x86/serpent-sse2 - convert to skcipher interface crypto: x86/serpent-avx2 - remove LRW algorithm crypto: x86/serpent-avx - remove LRW algorithm crypto: x86/serpent-avx,avx2 - convert to skcipher interface crypto: x86/twofish-3way - remove LRW algorithm crypto: x86/twofish-3way - remove XTS algorithm crypto: x86/twofish-3way - convert to skcipher interface crypto: x86/twofish-avx - remove LRW algorithm crypto: x86/twofish-avx - convert to skcipher interface crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one crypto: x86/cast5-avx - convert to skcipher interface crypto: x86/cast6-avx - remove LRW algorithm crypto: x86/cast6-avx - convert to skcipher interface crypto: x86/blowfish: convert to skcipher interface crypto: x86/des3_ede - convert to skcipher interface crypto: x86/camellia-aesni-avx - remove LRW algorithm crypto: x86/camellia-aesni-avx2 - remove LRW algorithm crypto: x86/camellia - remove LRW algorithm crypto: x86/camellia - remove XTS algorithm crypto: x86/camellia - convert to skcipher interface crypto: x86/camellia-aesni-avx, avx2 - convert to skcipher interface crypto: xts - remove xts_crypt() crypto: lrw - remove lrw_crypt() crypto: x86/glue_helper - remove blkcipher_walk functions crypto: x86/glue_helper - rename glue_skwalk_fpu_begin() crypto: ablk_helper - remove ablk_helper crypto: arm64/speck - add NEON-accelerated implementation of Speck-XTS Fabien DESSENNE (2): crypto: stm32/cryp - add aes gcm / ccm support crypto: stm32/cryp - add stm32mp1 support Fengguang Wu (1): crypto: ccree - fix memdup.cocci warnings Gary R Hook (3): crypto: ccp - Fill the result buffer only on digest, finup, and final ops crypto: ccp - Validate buffer lengths for copy operations crypto: doc - Document remaining members in struct crypto_alg Gilad Ben-Yossef (14): staging: ccree: rename staging ver and mark as broken crypto: ccree - introduce CryptoCell driver crypto: ccree - add skcipher support crypto: ccree - add ahash support crypto: ccree - add AEAD support crypto: ccree - add FIPS support MAINTAINERS: update ccree entry crypto: ccree - remove unused definitions dt-bindings: Add DT bindings for ccree 710 and 630p crypto: ccree - add support for older HW revs crypto: ccree - replace memset+kfree with kzfree crypto: sm4 - introduce SM4 symmetric cipher algorithm crypto: testmgr - introduce SM4 tests crypto: ccree - remove unused enums Gregory CLEMENT (5): hwrng: omap - Remove useless test before clk_disable_unprepare hwrng: omap - Fix clock resource by adding a register clock crypto: inside-secure - fix clock management crypto: inside-secure - improve clock initialization crypto: inside-secure - fix clock resource by adding a register clock Harsh Jain (6): crypto: chelsio - Use kernel round function to align lengths crypto: chelsio - Fix src buffer dma length crypto: chelsio - Update IV before sending request to HW crypto: chelsio - Fix iv passed in fallback path for rfc3686 crypto: chelsio -Split Hash requests for large scatter gather list crypto: chelsio - Remove declaration of static function from header Herbert Xu (5): crypto: api - Remove unused crypto_type lookup function crypto: api - Make crypto_alg_lookup static crypto: api - Keep failed instances alive crypto: lrw - Free rctx->ext with kzfree crypto: ahash - Fix early termination in hash walk Horia Geantă (4): crypto: caam/qi - return -EBADMSG for ICV check failure crypto: caam - prepare for gcm(aes) support over QI interface crypto: caam/qi - add GCM support crypto: doc - clarify hash callbacks state machine James Bottomley (2): crypto: cfb - add support for Cipher FeedBack mode crypto: ecdh - fix to allow multi segment scatterlists Jia-Ju Bai (3): crypto: rsa-pkcs1pad - Replace GFP_ATOMIC with GFP_KERNEL in pkcs1pad_encrypt_sign_complete crypto: user - Replace GFP_ATOMIC with GFP_KERNEL in crypto_report crypto: cavium - Replace mdelay with msleep in cpt_device_init Jinbum Park (1): crypto: arm/aes-cipher - move S-box to .rodata section Kamil Koniec
Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys
On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote: > > However, as it uses the exact same mechanism of the regular xts-aes-ccree > but takes the key from another source, I've marked it with a test of > alg_test_null() on the premise that if the xts-aes-ccree works, so must this. Well it appears to be stubbed out as cc_is_hw_key always returns false. > > Are there other crypto drivers doing this? > > I thought the exact same thing until I ran into a presentation about the s390 > secure keys implementation. I basically imitated their use (or abuse?) > of the Crypto API > assuming it is the way to go. > > Take a look at arch/s390/crypto/paes_s390.c It's always nice to discover code that was never reviewed. The general approach seems sane though. > Anyway, if this is not the way to go I'd be more than happy to do whatever > work is needed to create the right interface. > > PS. I'd be out of the office and away from email access to the coming week, so > kindly excuse any delay in response. I think it's fine. However, I don't really like the idea of everyone coming up with their own "paes", i.e., your patch's use of "haes". It should be OK to just use paes for everyone, no? As to your patch specifically, there is one issue where you're directly dereferencing the key as a struct. This is a no-no because the key may have come from user-space. You must treat it as a binary blob. The s390 code seems to do this correctly. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: rsa - remove unneeded initializations
On Tue, Apr 03, 2018 at 09:01:02AM +0300, Tudor Ambarus wrote: > > I set the err inside the if branch so that the compiler will > warn me in case of undefined value for err. Like here: > > https://rusty.ozlabs.org/?p=232 Yes but then sometimes the compiler will get it wrong and we will then have to add the initialisation for it and we'll be back to square one. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: ccree: remove unused enums
On Mon, Mar 26, 2018 at 08:32:18AM +0100, Gilad Ben-Yossef wrote: > Remove enums definitions unused in the driver code. > > Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com> Patch applied. Thanks. -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
