Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type
On Sat, Mar 24, 2018 at 12:02:42PM +0100, Stefan Agner wrote: > In the AES cases enum spu_cipher_type and enum hash_type have > the same values, so the assignment is fine. Explicitly cast > the enum type conversion. > > This fixes two warnings when building with clang: > drivers/crypto/bcm/cipher.c:821:34: warning: implicit conversion from > enumeration type 'enum spu_cipher_type' to different enumeration > type 'enum hash_type' [-Wenum-conversion] > hash_parms.type = cipher_parms.type; > ~ ~^~~~ > drivers/crypto/bcm/cipher.c:1412:26: warning: implicit conversion from > enumeration type 'enum spu_cipher_type' to different enumeration > type 'enum hash_type' [-Wenum-conversion] > hash_parms.type = ctx->cipher_type; > ~ ~^~~ > > Signed-off-by: Stefan Agner <ste...@agner.ch> 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/9] crypto: don't leak pointers to authenc keys
On Fri, Mar 23, 2018 at 12:42:15PM +0200, Tudor Ambarus wrote: > There are few places in crypto where we save pointers to the > authenc keys to a local variable of type struct crypto_authenc_keys > and we don't zeroize it after use. Fix all those cases and don't > leak pointers to the authenc keys. > > -- > > Changes in v2: > - add commit message on each patch > - add Jamie's and Christophe's Reviewed-by tag > > Tudor Ambarus (9): > crypto: authenc - don't leak pointers to authenc keys > crypto: authencesn - don't leak pointers to authenc keys > crypto: caam - don't leak pointers to authenc keys > crypto: caam/qi - don't leak pointers to authenc keys > crypto: chcr - don't leak pointers to authenc keys > crypto: ixp4xx - don't leak pointers to authenc keys > crypto: picoxcell - don't leak pointers to authenc keys > crypto: qat - don't leak pointers to authenc keys > crypto: talitos - don't leak pointers to authenc keys > > crypto/authenc.c | 11 +-- > crypto/authencesn.c | 11 +-- > drivers/crypto/caam/caamalg.c| 2 ++ > drivers/crypto/caam/caamalg_qi.c | 2 ++ > drivers/crypto/chelsio/chcr_algo.c | 5 + > drivers/crypto/ixp4xx_crypto.c | 2 ++ > drivers/crypto/picoxcell_crypto.c| 2 ++ > drivers/crypto/qat/qat_common/qat_algs.c | 3 +++ > drivers/crypto/talitos.c | 2 ++ > 9 files changed, 28 insertions(+), 12 deletions(-) Patches 3-9 applied. Please remove the unrelated changes from patches 1-2 and resubmit. 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 v1] crypto: Deduplicate le32_to_cpu_array() and cpu_to_le32_array()
On Wed, Mar 21, 2018 at 07:01:40PM +0200, Andy Shevchenko wrote: > Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them > to the generic header. > > No functional change implied. > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.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: talitos - fix IPsec cipher in length
On Thu, Mar 22, 2018 at 10:57:01AM +0100, Christophe Leroy wrote:
> For SEC 2.x+, cipher in length must contain only the ciphertext length.
> In case of using hardware ICV checking, the ICV length is provided via
> the "extent" field of the descriptor pointer.
>
> Cc: <sta...@vger.kernel.org> # 4.8+
> Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using
> HMAC_SNOOP_NO_AFEU")
> Reported-by: Horia Geantă <horia.gea...@nxp.com>
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
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: doc - clarify hash callbacks state machine
On Tue, Mar 20, 2018 at 09:56:12AM +0200, Horia Geantă wrote: > Add a note that it is perfectly legal to "abandon" a request object: > - call .init() and then (as many times) .update() > - _not_ call any of .final(), .finup() or .export() at any point in > future > > Link: https://lkml.kernel.org/r/20180222114741.ga27...@gondor.apana.org.au > 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 v2 0/9] crypto: inside-secure - hmac(sha256/sha224) support
On Mon, Mar 19, 2018 at 09:21:12AM +0100, Antoine Tenart wrote: > Hi Herbert, > > This series brings hmac(sha256) and hmac(sha224) support to the Inside > Secure cryptographic engine driver. > > The first 7 patches are fixes and reworks needed for the hmac(sha256) > and hmac(224) support to land in. Then 2 patches adds the 2 new > algorithms. > > This has been tested with boot tests, tcrypt and IPsec traffic. This > series is a preparation series for more algorithms support (so that > the series are smaller and easier to review). > > Thanks, > Antoine > > Since v1: > - Fixed a kbuild reported compilation issue. > - Added missing commit messages in the last 2 patches. > - Removed 3 patches from the series that already were applied in > the cryptodev tree. > > Antoine Tenart (9): > crypto: inside-secure - move the digest to the request context > crypto: inside-secure - fix typo s/allways/always/ in a define > crypto: inside-secure - fix a typo in a register name > crypto: inside-secure - improve the send error path > crypto: inside-secure - do not access buffers mapped to the device > crypto: inside-secure - improve the skcipher token > crypto: inside-secure - the context ipad/opad should use the state sz > crypto: inside-secure - hmac(sha256) support > crypto: inside-secure - hmac(sha224) support > > drivers/crypto/inside-secure/safexcel.c| 8 +- > drivers/crypto/inside-secure/safexcel.h| 6 +- > drivers/crypto/inside-secure/safexcel_cipher.c | 3 +- > drivers/crypto/inside-secure/safexcel_hash.c | 189 > +++++++++ > 4 files changed, 170 insertions(+), 36 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 1/1] crypto:chelsio - Remove declaration of static function from header
On Mon, Mar 19, 2018 at 07:06:22PM +0530, Harsh Jain wrote:
> It fixes compilation warning introduced in commit
>
> Introduced by commit
>
> 5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter
> gather list")
>
> Reported-by: Stephen Rothwell <s...@canb.auug.org.au>
> 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: [PATCH] crypto: rsa - remove unneeded initializations
On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote: > Remove useless assignment of ret to -ENOMEM in rsa_verify. > Remove useless initialization of ret to zero at declaration in > rsa_enc/dec/sign/verify. > > Benefit of the power of undefined values and set ret in branches in > rsa_enc/dec/sign. > > Reported-by: Benjamin Bales <techsupp...@mycode.ai> > Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> The existing code looks fine. If anything we should move the assignments out of the if clause. 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 2/2] crypto: ccree: enable support for hardware keys
On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote:
> Enable CryptoCell support for hardware keys.
>
> Hardware keys are regular AES keys loaded into CryptoCell internal memory
> via firmware, often from secure boot ROM or hardware fuses at boot time.
>
> As such, they can be used for enc/dec purposes like any other key but
> cannot (read: extremely hard to) be extracted since since they are not
> available anywhere in RAM during runtime.
>
> The mechanism has some similarities to s390 secure keys although the keys
> are not wrapped or sealed, but simply loaded offline. The interface was
> therefore modeled based on the s390 secure keys support.
>
> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
...
> static const struct cc_alg_template skcipher_algs[] = {
> {
> + .name = "xts(haes)",
> + .driver_name = "xts-haes-ccree",
> + .blocksize = AES_BLOCK_SIZE,
> + .template_skcipher = {
> + .setkey = cc_cipher_sethkey,
> + .encrypt = cc_cipher_encrypt,
> + .decrypt = cc_cipher_decrypt,
> + .min_keysize = CC_HW_KEY_SIZE,
> + .max_keysize = CC_HW_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + },
> + .cipher_mode = DRV_CIPHER_XTS,
> + .flow_mode = S_DIN_to_AES,
> + .min_hw_rev = CC_HW_REV_630,
> + },
How can this possibly pass the self-test?
If we want to add hardware keys we will need to figure out how
to deal with it in the top-level API first.
Are there other crypto drivers doing this?
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/9] crypto: authenc - don't leak pointers to authenc keys
On Fri, Mar 23, 2018 at 12:42:16PM +0200, 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>
> ---
> crypto/authenc.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/crypto/authenc.c b/crypto/authenc.c
> index d3d6d72..480a08b 100644
> --- a/crypto/authenc.c
> +++ b/crypto/authenc.c
> @@ -87,8 +87,10 @@ static int crypto_authenc_setkey(struct crypto_aead
> *authenc, const u8 *key,
> struct crypto_authenc_keys keys;
> int err = -EINVAL;
>
> - if (crypto_authenc_extractkeys(, key, keylen) != 0)
> - goto badkey;
> + if (crypto_authenc_extractkeys(, key, keylen) != 0) {
> + crypto_aead_set_flags(authenc, CRYPTO_TFM_RES_BAD_KEY_LEN);
> + goto out;
> + }
Why did you change this? The existing goto arrangement should work
fine even with your addition.
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] omap-crypto - fix kernel oops and output buffer update
Francis Le Bourse <francis.lebou...@sfr.fr> wrote: > Hi Tero, > >> I have a couple of additional comments, but can't add them as the patch >> content is an attachment (like, I would not add the WARN_ON.) Overall, >> the issue you have found is a legitimate problem, and should be fixed. > > I have used WARN_ON() to have some very visible output, I agree it is not > necessary. This error was possibly a side effect of the >out_sgl aes > bug and I haven't seen it since I have fixed the latter. When you resubmit a patch please indicate it in the Subject, e.g., with a v2, v3, and so on. Also please retain the complete patch description on each occasion. 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 Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote: > On (03/21/18 15:49), Nick Terrell wrote: > > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in > > Yikes! How come I missed that... :) > > > [0] > > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com > > Signed-off-by: Nick Terrell <terre...@fb.com> ? Please resend with sign-off. 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: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type
On Wed, Mar 28, 2018 at 05:41:30PM +0200, Stefan Agner wrote: > > Herbert, given that Raveendra agrees to the change, do you want me to > send a non-RFC version or can you merge the patch as is? There is no need to resend it. 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] SHASH_DESC_ON_STACK macro
On Fri, Mar 23, 2018 at 02:09:46PM -0500, Gustavo A. R. Silva wrote: > > Hi Herbert, > > There is an ongoing effort to remove all VLAs from the code base [1] and > while working on that I came across the following macro at > include/crypto/hash.h:154: > > #define SHASH_DESC_ON_STACK(shash, ctx) \ > char __##shash##_desc[sizeof(struct shash_desc) + \ > crypto_shash_descsize(ctx)] CRYPTO_MINALIGN_ATTR; \ > struct shash_desc *shash = (struct shash_desc *)__##shash##_desc > > > Currently, this macro is being used in 46 different places. > > I wonder how big can tfm->descsize can get? descsize is capped at PAGE_SIZE / 8. 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
[PATCH v2] crypto: ahash - Fix early termination in hash walk
On Sun, Mar 25, 2018 at 11:49:58PM +0800, Eli Cooper wrote:
> When supplied with an offset equal to PAGE_SIZE, the hash walk code returns
> zero, resulting in early termination and, in the observed scenario, memory
> corruption. This patch fixes it by clamping nbytes only when walk->offset
> is not at the PAGE_SIZE boundary.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eli Cooper <elicoo...@gmx.com>
> ---
> crypto/ahash.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/crypto/ahash.c b/crypto/ahash.c
> index 3a35d67de7d9..03cbe04c53b1 100644
> --- a/crypto/ahash.c
> +++ b/crypto/ahash.c
> @@ -46,8 +46,11 @@ static int hash_walk_next(struct crypto_hash_walk *walk)
> {
> unsigned int alignmask = walk->alignmask;
> unsigned int offset = walk->offset;
> - unsigned int nbytes = min(walk->entrylen,
> - ((unsigned int)(PAGE_SIZE)) - offset);
> + unsigned int pagelen, nbytes = walk->entrylen;
> +
> + pagelen = ((unsigned int)(PAGE_SIZE)) - offset;
> + if (pagelen)
> + nbytes = min(nbytes, pagelen);
hash_walk_next is only called from two places, neither of which
can produce an offset which is >= PAGE_SIZE.
> @@ -94,8 +97,9 @@ int crypto_hash_walk_done(struct crypto_hash_walk *walk,
> int err)
> walk->offset = ALIGN(walk->offset, alignmask + 1);
> walk->data += walk->offset;
>
> - nbytes = min(nbytes,
> - ((unsigned int)(PAGE_SIZE)) - walk->offset);
> + pagelen = ((unsigned int)(PAGE_SIZE)) - walk->offset;
> + if (pagelen)
> + nbytes = min(nbytes, pagelen);
> walk->entrylen -= nbytes;
Thanks, this bug is real. However, the fix is still wrong. What
happens is that we have just done the unaligned bit in the SG list
and now the page has been consumed. We should not return directly
in this case but move onto the next page.
---8<--
When we have an unaligned SG list entry where there is no leftover
aligned data, the hash walk code will incorrectly return zero as if
the entire SG list has been processed.
This patch fixes it by moving onto the next page instead.
Reported-by: Eli Cooper <elicoo...@gmx.com>
Cc: <sta...@vger.kernel.org>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/crypto/ahash.c b/crypto/ahash.c
index f732dd9..a64c143 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -92,13 +92,14 @@ int crypto_hash_walk_done(struct crypto_hash_walk *walk,
int err)
if (nbytes && walk->offset & alignmask && !err) {
walk->offset = ALIGN(walk->offset, alignmask + 1);
- walk->data += walk->offset;
-
nbytes = min(nbytes,
((unsigned int)(PAGE_SIZE)) - walk->offset);
walk->entrylen -= nbytes;
- return nbytes;
+ if (nbytes) {
+ walk->data += walk->offset;
+ return nbytes;
+ }
}
if (walk->flags & CRYPTO_ALG_ASYNC)
--
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: cavium: cpt: Replace mdelay with msleep in cpt_device_init
On Sun, Mar 18, 2018 at 10:50:38PM +0800, Jia-Ju Bai wrote: > cpt_device_init() is never called in atomic context. > > The call chain ending up at cpt_device_init() is: > [1] cpt_device_init() <- cpt_probe() > cpt_probe() is only set as ".probe" in pci_driver structure > "cpt_pci_driver". > > Despite never getting called from atomic context, cpt_device_init() calls > mdelay(100), i.e. busy wait for 100ms. > That is not necessary and can be replaced with msleep to > avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai <baijiaju1...@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] crypto: arm,arm64 - Fix random regeneration of S_shipped
Leonard Crestez <leonard.cres...@nxp.com> wrote: > The decision to rebuild .S_shipped is made based on the relative > timestamps of .S_shipped and .pl files but git makes this essentially > random. This means that the perl script might run anyway (usually at > most once per checkout), defeating the whole purpose of _shipped. > > Fix by skipping the rule unless explicit make variables are provided: > REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO. > > This can produce nasty occasional build failures downstream, for example > for toolchains with broken perl. The solution is minimally intrusive to > make it easier to push into stable. > > Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379 > > Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com> > Cc: <sta...@vger.kernel.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: doc - Document remaining members in struct crypto_alg
On Wed, Mar 14, 2018 at 05:15:52PM -0500, Gary R Hook wrote: > Add missing comments for union members ablkcipher, blkcipher, > cipher, and compress. This silences complaints when building > the htmldocs. > > Fixes: 0d7f488f0305a (crypto: doc - cipher data structures) > Signed-off-by: Gary R Hook <gary.h...@amd.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 19/47] crypto: remove blackfin CRC driver
On Wed, Mar 14, 2018 at 04:35:32PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so this > driver won't be used any more. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> 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] Keystone2 HW random generator
On Tue, Mar 13, 2018 at 01:33:29PM -0400, Vitaly Andrianov wrote: > Keyston2 Security Accelerator has a hardware random generator sub-module. > This series adds the driver for the sub-module. > > Changes in v2: > - Changed subject prefix in 1/2 patch > - renamed dts node > > Vitaly Andrianov (2): > dt-bindings: rng: add bindings doc for Keystone SA HWRNG driver > hw_random: keystone2: add hw_random driver > > .../devicetree/bindings/rng/ks-sa-rng.txt | 21 ++ > drivers/char/hw_random/Kconfig | 7 + > drivers/char/hw_random/Makefile| 1 + > drivers/char/hw_random/ks-sa-rng.c | 257 > + > 4 files changed, 286 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rng/ks-sa-rng.txt > create mode 100644 drivers/char/hw_random/ks-sa-rng.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 0/3] crypto: inside-secure: improve clock management
On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote: > Hi, > > This short series fixes the way the clocks are used for the SafeXcel > EIP-197 controller embedded in the Marvell Armada 7K/8K SoCs. On these > SoCs a second one is needed in order to clock the registers. It was > not noticed until now because we relied on the bootloader and also > because the clock driver was wrong. > > Thanks to this fix, it would be possible to fix the clock driver > without introducing a regression. > > While I was working on the clocks I found a bug in the clock > management which was fixed with the first patch and should be applied > to v4.16. I haven't applied it to the crypto 4.16 tree because your other patches depend on it and I don't think the issue doesn't seem to be that severe. In future it would help if you can avoid such dependencies if you wish the patches to go in as soon as possible. > The second patch is a small improvement which is aim for v4.17 as well > as the last patch. > > Thanks, > > Gregory > > Gregory CLEMENT (3): > crypto: inside-secure - fix clock management > crypto: inside-secure - improve clock initialization > crypto: inside-secure - fix clock resource by adding a register clock > > .../bindings/crypto/inside-secure-safexcel.txt | 6 ++- > drivers/crypto/inside-secure/safexcel.c| 47 > +++--- > drivers/crypto/inside-secure/safexcel.h| 1 + > 3 files changed, 38 insertions(+), 16 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 -next] crypto: fix missing unlock on error in safexcel_ahash_send_req()
On Tue, Mar 13, 2018 at 02:54:03PM +, Wei Yongjun wrote:
> Add the missing unlock before return from function
> safexcel_ahash_send_req() in the error handling case.
>
> Fixes: cff9a17545a3 ("crypto: inside-secure - move cache result dma mapping
> to request")
> Signed-off-by: Wei Yongjun <weiyongj...@huawei.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 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()
On Mon, Mar 12, 2018 at 02:32:58PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Mon, 12 Mar 2018 14:18:23 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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: ctr - avoid VLA use
On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote: > > +#define MAX_BLOCKSIZE 16 > + > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > +#define MAX_ALIGNMASK 15 > +#else > +#define MAX_ALIGNMASK 0 > +#endif > + Hmm, this won't work. Just because you have efficient unaligned access in general doesn't mean that every implementation can live with unaligned access. In particular, on x86 there are quite a few implementations that require alignment or they will fault. So please just make it 15 unconditionally. 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: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation
On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > From: Eric Biggers <ebigg...@google.com> > > If the pcrypt template is used multiple times in an algorithm, then a > deadlock occurs because all pcrypt instances share the same > padata_instance, which completes requests in the order submitted. That > is, the inner pcrypt request waits for the outer pcrypt request while > the outer request is already waiting for the inner. > > Fix this by making pcrypt forbid instantiation if pcrypt appears in the > underlying ->cra_driver_name. This is somewhat of a hack, but it's a > simple fix that should be sufficient to prevent the deadlock. I'm a bit uneasy with this fix. What if pcrypt is used in the underlying algorithm as a fallback? Wouldn't it still dead-lock without triggering this check? 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: lrw - Free rctx->ext with kzfree
The buffer rctx->ext contains potentially sensitive data and should
be freed with kzfree.
Cc: <sta...@vger.kernel.org>
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/crypto/lrw.c b/crypto/lrw.c
index a09cdaa..954a706 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -317,7 +317,7 @@ static void exit_crypt(struct skcipher_request *req)
rctx->left = 0;
if (rctx->ext)
- kfree(rctx->ext);
+ kzfree(rctx->ext);
}
static int do_encrypt(struct skcipher_request *req, int err)
--
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/9] don't leak pointers to authenc keys
On Wed, Mar 21, 2018 at 07:00:48PM +0200, Tudor Ambarus wrote: > There are few places in crypto where we save pointers to the > authenc keys to a local variable of type struct crypto_authenc_keys > and we don't zeroize it after use. Fix all those cases and don't > leak pointers to the authenc keys. Please put this blurb into each patch description. Because when people look up the commit years from now they won't be able to find this email. 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: api - Keep failed instances alive
This patch reverts commit 9c521a200bc3 ("crypto: api - remove
instance when test failed") and fixes the underlying problem
in a different way.
To recap, prior to the reverted commit, an instance that fails
a self-test is kept around. However, it would satisfy any new
lookups against its name and therefore the system may accumlulate
an unbounded number of failed instances for the same algorithm
name.
The reverted commit fixed it by unregistering the instance. Hoever,
this still does not prevent the creation of the same failed instance
over and over again each time the name is looked up.
This patch fixes it by keeping the failed instance around, just as
we would if it were a normal algorithm. However, the lookup code
has been udpated so that we do not attempt to create another
instance as long as this failed one is still registered. Of course,
you could still force a new creation by deleting the instance from
user-space.
A new error (ELIBBAD) has been commandeered for this purpose and
will be returned when all registered algorithm of a given name
have failed the self-test.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 395b082..2a0271b 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -543,9 +543,6 @@ int crypto_register_instance(struct crypto_template *tmpl,
inst->alg.cra_module = tmpl->module;
inst->alg.cra_flags |= CRYPTO_ALG_INSTANCE;
- if (unlikely(!crypto_mod_get(>alg)))
- return -EAGAIN;
-
down_write(_alg_sem);
larval = __crypto_register_alg(>alg);
@@ -563,14 +560,9 @@ int crypto_register_instance(struct crypto_template *tmpl,
goto err;
crypto_wait_for_test(larval);
-
- /* Remove instance if test failed */
- if (!(inst->alg.cra_flags & CRYPTO_ALG_TESTED))
- crypto_unregister_instance(inst);
err = 0;
err:
- crypto_mod_put(>alg);
return err;
}
EXPORT_SYMBOL_GPL(crypto_register_instance);
diff --git a/crypto/api.c b/crypto/api.c
index 99f4dc9..ccb1ddf 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -197,9 +197,16 @@ static struct crypto_alg *crypto_alg_lookup(const char
*name, u32 type,
u32 mask)
{
struct crypto_alg *alg;
+ u32 test = 0;
+
+ if (!((type | mask) & CRYPTO_ALG_TESTED))
+ test |= CRYPTO_ALG_TESTED;
down_read(_alg_sem);
- alg = __crypto_alg_lookup(name, type, mask);
+ alg = __crypto_alg_lookup(name, type | test, mask | test);
+ if (!alg && test)
+ alg = __crypto_alg_lookup(name, type, mask) ?
+ ERR_PTR(-ELIBBAD) : NULL;
up_read(_alg_sem);
return alg;
@@ -227,10 +234,12 @@ static struct crypto_alg *crypto_larval_lookup(const char
*name, u32 type,
alg = crypto_alg_lookup(name, type, mask);
}
- if (alg)
- return crypto_is_larval(alg) ? crypto_larval_wait(alg) : alg;
+ if (!IS_ERR_OR_NULL(alg) && crypto_is_larval(alg))
+ alg = crypto_larval_wait(alg);
+ else if (!alg)
+ alg = crypto_larval_add(name, type, mask);
- return crypto_larval_add(name, type, mask);
+ return alg;
}
int crypto_probing_notify(unsigned long val, void *v)
@@ -253,11 +262,6 @@ struct crypto_alg *crypto_alg_mod_lookup(const char *name,
u32 type, u32 mask)
struct crypto_alg *larval;
int ok;
- if (!((type | mask) & CRYPTO_ALG_TESTED)) {
- type |= CRYPTO_ALG_TESTED;
- mask |= CRYPTO_ALG_TESTED;
- }
-
/*
* If the internal flag is set for a cipher, require a caller to
* to invoke the cipher with the internal flag to use that cipher.
--
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: api - Remove unused crypto_type lookup function
The lookup function in crypto_type was only used for the implicit
IV generators which have been completely removed from the crypto
API.
This patch removes the lookup function as it is now useless.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/crypto/api.c b/crypto/api.c
index 70a894e..0e9cd20 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -485,20 +485,14 @@ struct crypto_alg *crypto_find_alg(const char *alg_name,
const struct crypto_type *frontend,
u32 type, u32 mask)
{
- struct crypto_alg *(*lookup)(const char *name, u32 type, u32 mask) =
- crypto_alg_mod_lookup;
-
if (frontend) {
type &= frontend->maskclear;
mask &= frontend->maskclear;
type |= frontend->type;
mask |= frontend->maskset;
-
- if (frontend->lookup)
- lookup = frontend->lookup;
}
- return lookup(alg_name, type, mask);
+ return crypto_alg_mod_lookup(alg_name, type, mask);
}
EXPORT_SYMBOL_GPL(crypto_find_alg);
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index e3cebf6..1aba888 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -30,7 +30,6 @@ struct crypto_type {
int (*init_tfm)(struct crypto_tfm *tfm);
void (*show)(struct seq_file *m, struct crypto_alg *alg);
int (*report)(struct sk_buff *skb, struct crypto_alg *alg);
- struct crypto_alg *(*lookup)(const char *name, u32 type, u32 mask);
void (*free)(struct crypto_instance *inst);
unsigned int type;
--
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 v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT
On Mon, Mar 19, 2018 at 11:31:24PM +0800, Ard Biesheuvel wrote: > > Apologies if this wasn't clear, but there are some cross dependencies > with the arm64 tree, which receives non-trivial modifications in > patches 10 and 11, which are subsequently depended upon by patches 12 > - 23. > > Without acks from them, we should really not be merging this code yet, > especially because I noticed a rebase issue in patch #10 (my bad). > > Would you mind reverting 10 - 22? I will revisit this asap, and try to > get acks for the arm64 patches. If that means waiting for the next > cycle, so be it. Sure it's done now. 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: doc - clarify hash callbacks state machine
On Mon, Mar 19, 2018 at 11:04:24AM +, Horia Geantă wrote: > > The only solution to avoid leaks in this case is to repeatedly DMA map & unmap > the buffer. > IOW, if one wants to load/save HW state in a buffer after an .update() and to > instruct the crypto engine to do this operation, the following steps are > involved: > -gpp: DMA map the buffer, get its IOVA > -gpp: program the crypto engine with IOVA, wait for crypto engine's signal > -crypto engine: load HW state from buffer, perform the partial hash, save HW > state in buffer, signal gpp > -gpp: DMA unmap the buffer What buffer are you talking about here? Is it the hash state? If it's the hash state and assuming DMA mapping was slow enough on your platform, you could solve it by maintaining a fixed set of hash states that are rotated through the actual hash requests. Let's say you allocate n such hash states which are always mapped, then if there are less than n hash requests outstanding, you could directly use the mapped hash states in the requests. If there are more than n, then you simply copy in/copy out for each hash operation. The number n limits how many operations can be pending to be processed by the hardware. 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: doc - clarify hash callbacks state machine
On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote: > > The fact that there can be multiple requests in parallel (for a given tfm) is > a > different topic. > Each request object has its state in its own state machine, independent from > the > other request objects. > I assume this is clear enough. My point is that all of the state associated with a request needs to be stored in the request object. If you're start storing things in the driver/hardware, then things will get ugly one way or another. 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 v11 crypto 00/12] Chelsio Inline TLS
On Sun, Mar 18, 2018 at 10:36:02AM -0400, David Miller wrote: > > Herbert, is it OK for this entire series to go via net-next? Sure, although there could be conflicts since the chelsio driver seems to be changing quite fast. 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: x86/des3_ede: make array des3_ede_skciphers static
On Mon, Mar 05, 2018 at 02:18:00PM +0100, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > The array des3_ede_skciphers is local to the source and does not need > to be in global scope, so make it static. > > Cleans up sparse warning: > arch/x86/crypto/des3_ede_glue.c:407:21: warning: symbol > 'des3_ede_skciphers' was not declared. Should it be static? > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> This patch no longer applies because it's already been merged from someone else. 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 v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT
On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote: > As reported by Sebastian, the way the arm64 NEON crypto code currently > keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is > causing problems with RT builds, given that the skcipher walk API may > allocate and free temporary buffers it uses to present the input and > output arrays to the crypto algorithm in blocksize sized chunks (where > blocksize is the natural blocksize of the crypto algorithm), and doing > so with NEON enabled means we're alloc/free'ing memory with preemption > disabled. > > This was deliberate: when this code was introduced, each kernel_neon_begin() > and kernel_neon_end() call incurred a fixed penalty of storing resp. > loading the contents of all NEON registers to/from memory, and so doing > it less often had an obvious performance benefit. However, in the mean time, > we have refactored the core kernel mode NEON code, and now kernel_neon_begin() > only incurs this penalty the first time it is called after entering the > kernel, > and the NEON register restore is deferred until returning to userland. This > means pulling those calls into the loops that iterate over the input/output > of the crypto algorithm is not a big deal anymore (although there are some > places in the code where we relied on the NEON registers retaining their > values between calls) > > So let's clean this up for arm64: update the NEON based skcipher drivers to > no longer keep the NEON enabled when calling into the skcipher walk API. > > As pointed out by Peter, this only solves part of the problem. So let's > tackle it more thoroughly, and update the algorithms to test the NEED_RESCHED > flag each time after processing a fixed chunk of input. > > Given that this issue was flagged by the RT people, I would appreciate it > if they could confirm whether they are happy with this approach. > > Changes since v4: > - rebase onto v4.16-rc3 > - apply the same treatment to new SHA512, SHA-3 and SM3 code that landed > in v4.16-rc1 Looks good to me. If more work is needed we can always do incremental fixes. Patches 1-22 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: Remove stack VLA usage
On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this switches to > a pair of kmalloc regions instead of using the stack. This also moves > the get_random_bytes() after all allocations (and drops the needless > "nbytes" variable). > > [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] crypto: virtio - remove dependency on CRYPTO_AUTHENC
On Wed, Mar 07, 2018 at 12:53:15AM +0100, Peter Wu wrote:
> virtio_crypto does not use function crypto_authenc_extractkeys, remove
> this unnecessary dependency. Compiles fine and passes cryptodev-linux
> cipher and speed tests from https://wiki.qemu.org/Features/VirtioCrypto
>
> Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
> Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
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: ccp: Use memdup_user() rather than duplicating its implementation
On Mon, Mar 05, 2018 at 02:10:20PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Mon, 5 Mar 2018 13:50:13 +0100 > > Reuse existing functionality from memdup_user() instead of keeping > duplicate source code. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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: hash.h: Prevent use of req->result in ahash update
On Wed, Mar 07, 2018 at 11:49:33AM +0100, Kamil Konieczny wrote: > Prevent improper use of req->result field in ahash update, init, export and > import functions in drivers code. A driver should use ahash request context > if it needs to save internal state. > > Signed-off-by: Kamil Konieczny <k.koniec...@partner.samsung.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/ccp: Validate buffer lengths for copy operations
On Wed, Mar 07, 2018 at 11:31:14AM -0600, Gary R Hook wrote: > The CCP driver copies data between scatter/gather lists and DMA buffers. > The length of the requested copy operation must be checked against > the available destination buffer length. > > Reported-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name> > Signed-off-by: Gary R Hook <gary.h...@amd.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] crypto: introduce SM4 symmetric cipher algorithm
On Tue, Mar 06, 2018 at 09:44:41AM +, Gilad Ben-Yossef wrote: > Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016) and > related tests. > > SM4 (GBT.32907-2016) is a cryptographic standard issued by the > Organization of State Commercial Administration of China (OSCCA) > as an authorized cryptographic algorithms for the use within China. > > SMS4 was originally created for use in protecting wireless > networks, and is mandated in the Chinese National Standard for > Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure) > (GB.15629.11-2003). > > Tested on arm 64 and 32 bit. > > Gilad Ben-Yossef (2): > crypto: introduce SM4 symmetric cipher algorithm > crypto: introduce SM4 testmgr tests > > crypto/Kconfig | 25 ++ > crypto/Makefile | 1 + > crypto/sm4_generic.c | 244 > +++ > crypto/tcrypt.c | 3 + > crypto/testmgr.c | 9 ++ > crypto/testmgr.h | 131 +++ > include/crypto/sm4.h | 28 ++ > 7 files changed, 441 insertions(+) > create mode 100644 crypto/sm4_generic.c > create mode 100644 include/crypto/sm4.h 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/5] crypto:chelsio: Bug fixes and cleanup
On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote: > It includes bug fixes and code cleanup. > > Changes from v1: > > Remove Redundant soffset initialisation from 2/5. > > Harsh Jain (5): > 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 > > drivers/crypto/chelsio/chcr_algo.c | 465 > --- > drivers/crypto/chelsio/chcr_algo.h | 11 +- > drivers/crypto/chelsio/chcr_core.h | 6 +- > drivers/crypto/chelsio/chcr_crypto.h | 32 ++- > 4 files changed, 354 insertions(+), 160 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 0/2] hwrng: mxc-rnga - add driver support on boards with device tree
On Tue, Mar 06, 2018 at 12:20:58AM +0200, Vladimir Zapolskiy wrote:
> The series is a trivial change to extend Freescale i.MX31 RNGA
> driver to work on boards with device description taken from device
> tree blob. The change was tested on a legacy LogicPD MX31Lite board.
>
> Vladimir Zapolskiy (2):
> dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles
> hwrng: mxc-rnga - add driver support on boards with device tree
>
> Changes from v1 to v2:
> * a kernel for iMX boards is always built with multiplatform support,
> thus CONFIG_OF guards were removed, thanks to Kim Phillips for review,
> * added i.MX21 RNGA compatible, i.MX31 RNGA is backward compatible to it,
> * though the list of documented compatibles is extended, I dare to add
> Rob's Reviewed-by tag casted for v1.
>
> .../bindings/rng/{imx-rngc.txt => imx-rng.txt} | 11 +--
> drivers/char/hw_random/mxc-rnga.c | 23
> +-
> 2 files changed, 19 insertions(+), 15 deletions(-)
> rename Documentation/devicetree/bindings/rng/{imx-rngc.txt => imx-rng.txt}
> (54%)
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: [RFC PATCH] crypto: arm64/speck - add NEON-accelerated implementation of Speck-XTS
On Mon, Mar 05, 2018 at 11:17:07AM -0800, Eric Biggers wrote: > Add a NEON-accelerated implementation of Speck128-XTS and Speck64-XTS > for ARM64. This is ported from the 32-bit version. It may be useful on > devices with 64-bit ARM CPUs that don't have the Cryptography > Extensions, so cannot do AES efficiently -- e.g. the Cortex-A53 > processor on the Raspberry Pi 3. > > It generally works the same way as the 32-bit version, but there are > some slight differences due to the different instructions, registers, > and syntax available in ARM64 vs. in ARM32. For example, in the 64-bit > version there are enough registers to hold the XTS tweaks for each > 128-byte chunk, so they don't need to be saved on the stack. > > Benchmarks on a Raspberry Pi 3 running a 64-bit kernel: > >Algorithm Encryption Decryption >- -- -- >Speck64/128-XTS (NEON) 92.2 MB/s 92.2 MB/s >Speck128/256-XTS (NEON)75.0 MB/s 75.0 MB/s >Speck128/256-XTS (generic) 47.4 MB/s 35.6 MB/s >AES-128-XTS (NEON bit-sliced) 33.4 MB/s 29.6 MB/s >AES-256-XTS (NEON bit-sliced) 24.6 MB/s 21.7 MB/s > > The code performs well on higher-end ARM64 processors as well, though > such processors tend to have the Crypto Extensions which make AES > preferred. For example, here are the same benchmarks run on a HiKey960 > (with CPU affinity set for the A73 cores), with the Crypto Extensions > implementation of AES-256-XTS added: > >Algorithm Encryption Decryption >- ------ >AES-256-XTS (Crypto Extensions)1273.3 MB/s1274.7 MB/s >Speck64/128-XTS (NEON) 359.8 MB/s 348.0 MB/s >Speck128/256-XTS (NEON) 292.5 MB/s 286.1 MB/s >Speck128/256-XTS (generic) 186.3 MB/s 181.8 MB/s >AES-128-XTS (NEON bit-sliced) 142.0 MB/s 124.3 MB/s >AES-256-XTS (NEON bit-sliced) 104.7 MB/s 91.1 MB/s > > 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] crypto: doc - clarify hash callbacks state machine
On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: > Even though it doesn't make too much sense, it is perfectly legal to: > - call .init() and then (as many times) .update() > - subseqently _not_ call any of .final(), .finup() or .export() Actually it makes perfect sense, because there can be an arbitrary number of requests for a given tfm. There is no requirement that you must finalise the first request before submitting new ones. IOW there can be an arbitrary number of outstanding requests even without the user intentionally abandoning any hash request. So please modify your commit description. 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 Thu, Jan 18, 2018 at 04:44:21PM -0800, Megha Dey wrote: > > > So the mcryptd template is in fact completely superfluous. You > > can remove it and just have all the main encrypt/decrypt functions > > invoke the underlying encrypt/decrypt function directly and achieve > > the same result. > > > > Am I missing something? > > Hi Herbert, > > After discussing with Tim, it seems like the mcryptd is responsible for > queuing up the encrypt requests and dispatching them to the actual > multi-buffer raw algorithm. It also flushes the queue > if we wait too long without new requests coming in to force dispatch of > the requests in queue. > > Its function is analogous to cryptd but it has its own multi-lane twists > so we haven't reused the cryptd interface. 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? 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 00/12] crypto: inside-secure - hmac(sha256/sha224) support
On Thu, Mar 15, 2018 at 04:45:54PM +0100, Antoine Tenart wrote: > > I made a small mistake as the first 3 patches of the series already > were merged into your tree, as they already were sent in a previous > series. You can just ignore them. OK. 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: [Blackfin removal] [PATCH 18/28] crypto: Remove Blackfin crypto support
On Thu, Mar 15, 2018 at 03:49:33PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 11:50 AM, Aaron Wu <aaron...@analog.com> wrote:
> > Signed-off-by: Aaron Wu <aaron...@analog.com>
> >
> > Remove Blackfin crypto support
> > ---
> > crypto/testmgr.c | 6 -
> > crypto/testmgr.h | 88 --
>
> I'm not sure about this one: while the function name indicates that this is
> blackfin specific, my reading of the code is that it would also apply to
> any other crc32 accelerator like drivers/crypto/stm32/stm32_crc32.c
>
> Should I include this removal in my series or not?
Please send all these bfin_crc patches through the crypto tree.
> > diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> > index d5e23a1..8dacd69 100644
> > --- a/crypto/testmgr.c
> > +++ b/crypto/testmgr.c
> > @@ -3070,12 +3070,6 @@ static const struct alg_test_desc alg_test_descs[] =
> > {
> > .hash = __VECS(ghash_tv_template)
> > }
> > }, {
> > - .alg = "hmac(crc32)",
> > - .test = alg_test_hash,
> > - .suite = {
> > - .hash = __VECS(bfin_crc_tv_template)
> > - }
> > - }, {
Yes this should be removed. While we do still have other crc32
implementations and you could apply the hmac template on them,
it makes no sense to do so and nobody provides a direct hmac(crc32)
implementation.
So there is no point for this test vector to exist.
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: ctr: avoid VLA use
On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding hw require 16 bits > alignment for the block buffer. > We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bits > alignment, unless the architecture support efficient unaligned > accesses. > We also check, at runtime, that our assumptions still stand, > possibly dynamically allocating a new buffer, just in case > something changes in the future. Please move the check to ctr instance creation time. That is, if the underlying blocksize is greater than 16 bytes than simply fail the creation. 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: [RFC PATCH cryptodev] crypto: des3_ede_skciphers[] can be static
On Sat, Mar 03, 2018 at 04:29:46AM +0800, kbuild test robot wrote:
>
> Fixes: 09c0f03bf8ce ("crypto: x86/des3_ede - convert to skcipher interface")
> Signed-off-by: Fengguang Wu <fengguang...@intel.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/ccp - Fill the result buffer only on digest, finup, and final ops
On Wed, Mar 07, 2018 at 11:37:42AM -0600, Gary R Hook wrote:
> Any change to the result buffer should only happen on final, finup
> and digest operations. Changes to the buffer for update, import, export,
> etc, are not allowed.
>
> Fixes: 66d7b9f6175e ("crypto: testmgr - test misuse of result in ahash")
> Signed-off-by: Gary R Hook <gary.h...@amd.com>
> Cc: <sta...@vger.kernel.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:Chelsio: no csum offload for ipsec path
On Wed, Feb 28, 2018 at 11:18:08PM +0530, Atul Gupta wrote: > The Inline IPSec driver does not offload csum. > > 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 0/2] add crypto support for TPM communication
James Bottomley <james.bottom...@hansenpartnership.com> wrote: > To support cryptographic communication with the TPM, we need to add > Cipher FeedBack (CFB) mode for stream encryption because this is the > mandated encryption scheme for all encrypted parameters and responses. > Additionally, we ran across a problem in the elliptic curve routines > in that the size of the scatterlist is hard coded to 1 which causes a > kernel BUG if you use a longer scatterlist. Since all the current > kernel consumers use a single element scatterlist, this bug won't > manifest until we add the TPM routines to use crypto, so I didn't mark > it for stable. > > James Bottomley (2): > crypto: cfb: add support for Cipher FeedBack mode > crypto: ecdh: fix to allow multi segment scatterlists > > crypto/Kconfig | 8 ++ > crypto/Makefile | 1 + > crypto/cfb.c| 353 > crypto/ecdh.c | 23 +++- > 4 files changed, 379 insertions(+), 6 deletions(-) > create mode 100644 crypto/cfb.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 1/4] crypto: omap-sham: Remove useless check for non-null request
On Thu, Mar 01, 2018 at 09:50:10PM +0100, Krzysztof Kozlowski wrote: > ahash_request 'req' argument passed by the caller > omap_sham_handle_queue() cannot be NULL here because it is obtained from > non-NULL pointer via container_of(). > > This fixes smatch warning: > drivers/crypto/omap-sham.c:812 omap_sham_prepare_request() warn: variable > dereferenced before check 'req' (see line 805) > > Signed-off-by: Krzysztof Kozlowski <k...@kernel.org> 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] hwrng: omap: Fix clock resource for Armada 7K/8K
On Wed, Feb 28, 2018 at 03:27:21PM +0100, Gregory CLEMENT wrote: > Hi, > > This short series fixes the way the clocks are used for the SafeXcel > IP-76 controller embedded in the Marvell Armada 7K/8K SoCs. On these > SoCs a second one is needed in order to clock the registers. It was > not noticed until now because we relied on the bootloader and also > because the clock driver was wrong. > > Thanks to this fix, it would be possible to fix the clock driver > without introducing a regression. > > The first patch is just a small cleanup found when I wrote the main > patch. > > Gregory CLEMENT (2): > hwrng: omap - Remove useless test before clk_disable_unprepare > hwrng: omap - Fix clock resource by adding a register clock > > Documentation/devicetree/bindings/rng/omap_rng.txt | 7 ++- > drivers/char/hw_random/omap-rng.c | 22 > ++ > 2 files changed, 24 insertions(+), 5 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 2/2] crypto: talitos - do not perform unnecessary dma synchronisation
On Mon, Feb 26, 2018 at 05:40:06PM +0100, Christophe Leroy wrote: > req_ctx->hw_context is mainly used only by the HW. So it is not needed > to sync the HW and the CPU each time hw_context in DMA mapped. > This patch modifies the DMA mapping in order to limit synchronisation > to necessary situations. > > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> 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: omap: fixes + tweaks for omap crypto
On Tue, Feb 27, 2018 at 03:30:33PM +0200, Tero Kristo wrote: > Hi, > > This series contains a couple of fixes for LPAE data handling (patch #1/#2), > and also a few configuration patches (#3..#6.) Without the fixes, > the driver will see crashes in certain data configs, most notably when > using cryptodev and passing data buffers from userspace. All these > patches can be targeted for 4.17 merge window. > > The configuration patches make certain parameters for omap crypto drivers > user configurable, which helps optimizing performance on different HW > configurations, and also avoiding buffer overflows when using for example > UDP protocol for ipsec. The queue size patches are maybe more controversial, > but I could not find anybody modifying the queue sizes for now. Should there > be a separate API for this purpose or what would be preferable? 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 1/2] crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf
On Mon, Feb 26, 2018 at 05:40:04PM +0100, Christophe Leroy wrote:
> Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping
> outside the requests") introduced a persistent dma mapping of
> req_ctx->hw_context
> Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash
> on SEC1") introduced a persistent dma mapping of req_ctx->buf
>
> As there is no destructor for req_ctx (the request context), the
> associated dma handlers where set in ctx (the tfm context). This is
> wrong as several hash operations can run with the same ctx.
>
> This patch removes this persistent mapping.
>
> Reported-by: Horia Geanta <horia.gea...@nxp.com>
> Fixes: 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the
> requests")
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
> SEC1")
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
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: cavium: make two functions static
On Mon, Feb 26, 2018 at 02:51:19PM +, Colin King wrote: > From: Colin Ian King <colin.k...@canonical.com> > > Functions cavium_rng_remove and cavium_rng_remove_vf are local to the > source and do not need to be in global scope, so make them static. > > Cleans up sparse warnings: > drivers/char/hw_random/cavium-rng-vf.c:80:7: warning: symbol > 'cavium_rng_remove_vf' was not declared. Should it be static? > drivers/char/hw_random/cavium-rng.c:65:7: warning: symbol > 'cavium_rng_remove' was not declared. Should it be static? > > 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 0/3] crypto: inside-secure - fixes for heavy load usage
On Mon, Feb 26, 2018 at 02:45:09PM +0100, Antoine Tenart wrote: > Hi Herbert, > > This series contains 3 patches aimed at fixing issues when the SafeXcel > driver is used under heavy load. The first two patches move DMA mapping > informations to per-request specific contexts and the last one handles > the case where the digest return code is -EBUSY (i.e. when a queued > request end up in the backlog). > > Hopefully this series will be the last fixes one before adding more > features :) > > This is based on top of v4.16-rc1 and the already accepted SafeXcel > patches (series "crypto: inside-secure - stabilization and fixes"). > > Thanks! > Antoine > > Antoine Tenart (2): > crypto: inside-secure - move cache result dma mapping to request > crypto: inside-secure - wait for the request to complete if in the > backlog > > Ofer Heifetz (1): > crypto: inside-secure - move hash result dma mapping to request > > drivers/crypto/inside-secure/safexcel.c | 19 - > drivers/crypto/inside-secure/safexcel.h | 9 - > drivers/crypto/inside-secure/safexcel_hash.c | 59 > ++------ > 3 files changed, 30 insertions(+), 57 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 3/4] crypto: bcm: Constify *hash_alg_name[]
On Fri, Mar 09, 2018 at 06:35:35AM -0800, Joe Perches wrote: > > and likely, as this is a global name, it should > be something like crypto_hash_alg_name crypto_ is not a good prefix here. Perhaps crypto_bcm_. 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 3/4] crypto: bcm: Constify *hash_alg_name[]
On Tue, Feb 27, 2018 at 07:01:27PM -0300, Hernán Gonzalez wrote:
> Note: This is compile only tested.
> No gain from this except some self-documenting.
>
> Signed-off-by: Hernán Gonzalez <her...@vanguardiasur.com.ar>
> ---
> drivers/crypto/bcm/spu.c | 5 +++--
> drivers/crypto/bcm/spu.h | 2 +-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/bcm/spu.c b/drivers/crypto/bcm/spu.c
> index efaf3cf..c7bb79e 100644
> --- a/drivers/crypto/bcm/spu.c
> +++ b/drivers/crypto/bcm/spu.c
> @@ -23,8 +23,9 @@
> #include "cipher.h"
>
> /* This array is based on the hash algo type supported in spu.h */
> -char *hash_alg_name[] = { "None", "md5", "sha1", "sha224", "sha256", "aes",
> - "sha384", "sha512", "sha3_224", "sha3_256", "sha3_384", "sha3_512" };
> +char const * const hash_alg_name[] = { "None", "md5", "sha1", "sha224",
Please make that
const char *const
Ditto with patch 4.
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 0/4] crypto: AF_ALG AIO improvements
On Tue, Feb 27, 2018 at 03:08:58PM +0100, Stephan Müller wrote: > Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: > > Hi Herbert, > > > On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > > A simple copy operation, however, will imply that in one AIO recvmsg > > > request, only *one* IOCB can be set and processed. > > > > Sure, but the recvmsg will return as soon as the crypto API encrypt > > or decrypt function returns. It's still fully async. It's just > > that the setup part needs to be done with sendmsg/recvmsg. > > Wouldn't a copy of the ctx->iv into a per-request buffer change the behavoir > of the AF_ALG interface significantly? > > Today, if multiple IOCBs are submitted, most cipher implementations would > serialize the requests (e.g. all implementations that behave synchronous in > nature like all software implementations). No there is no such guarantee. In fact I'm pretty sure such users would be totally broken if cryptd was used. 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 v2 0/5] crypto:chelsio: Bug fixes and cleanup
On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote: > It includes bug fixes and code cleanup. > > Changes from v1: > > Remove Redundant soffset initialisation from 2/5. Hmm, the first series has already been applied. So if you want to change it then you'll need to send patches based on that. 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: Why are we testing an intermediate result in ahash?
On Mon, Mar 05, 2018 at 02:30:57PM -0600, Gary R Hook wrote:
>
> So a failure to communicate a newly-required behavior change, much less
> document it, is addressed by breaking drivers? For some reason this seems
> wrong.
>
> It's also wrong to change the documentation after the fact, and after
> surprising people. The documentation change should have gone in with the
> change to testmgr. And all that -after- doing as suggested below.
You should never touch req->result unless you're finalising the hash.
This has always been the case, it's just never been tested by the
test frame work and therefore some buggy drivers have slipped
through.
The generic implementation (e.g., crypto/sha1_generic.c) is always
the authoritative source when it comes to driver behaviour.
Anyway, rather than wasting time debating this, you could've just
spent a couple of minutes fixing your driver.
---8<---
Subject: crypto: ccp - Do not touch result buffer except on final
The req->final buffer should only be modified when writing the
final hash. It is not meant to be used to write incomplete hashes
when performing an update operation.
Fixes: 466d7b9f6175 ("crypto: testmgr - test misuse of result in...")
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
index 60fc0fa..acc8c64 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
@@ -45,8 +45,8 @@ static int ccp_aes_cmac_complete(struct crypto_async_request
*async_req,
rctx->buf_count = 0;
}
- /* Update result area if supplied */
- if (req->result)
+ /* Update result area if final */
+ if (rctx->final)
memcpy(req->result, rctx->iv, digest_size);
e_free:
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c
b/drivers/crypto/ccp/ccp-crypto-sha.c
index 8b9b16d..e290836 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -46,8 +46,8 @@ static int ccp_sha_complete(struct crypto_async_request
*async_req, int ret)
rctx->buf_count = 0;
}
- /* Update result area if supplied */
- if (req->result)
+ /* Update result area if final. */
+ if (rctx->final)
memcpy(req->result, rctx->ctx, digest_size);
e_free:
--
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: Why are we testing an intermediate result in ahash?
On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote: > Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for > async hash operations, the result buffer with a known value and to test the > buffer against that value at intermediate steps. If the result buffer > changes the operation is failed. > > My question is: why? The problem is that you must not touch the result buffer unless you're doing a finalisation. Indeed, the caller may have provided a NULL pointer for what it's worth. 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/3] crypto: ccp - return an actual key size from RSA max_size callback
On Sat, Mar 03, 2018 at 12:15:20AM +0100, Maciej S. Szmigiero wrote: > > However, what about the first patch from this series? > Without it, while it no longer should cause a buffer overflow, in-kernel > X.509 certificate verification will still fail with CCP driver loaded > (since CCP RSA implementation has a higher priority than the software > RSA implementation). That normally goes through the security tree. 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/3] crypto: ccp - return an actual key size from RSA max_size callback
On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
> rsa-pkcs1pad uses a value returned from a RSA implementation max_size
> callback as a size of an input buffer passed to the RSA implementation for
> encrypt and sign operations.
>
> CCP RSA implementation uses a hardware input buffer which size depends only
> on the current RSA key length, so it should return this key length in
> the max_size callback, too.
> This also matches what the kernel software RSA implementation does.
>
> Previously, the value returned from this callback was always the maximum
> RSA key size the CCP hardware supports.
> This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even
> for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd()
> tried to copy this large input buffer into a RSA key length-sized hardware
> input buffer.
>
> Signed-off-by: Maciej S. Szmigiero <m...@maciej.szmigiero.name>
> Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP")
> Cc: sta...@vger.kernel.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/ccp: don't disable interrupts while setting up debugfs
On Fri, Feb 23, 2018 at 11:33:07PM +0100, Sebastian Andrzej Siewior wrote: > I don't why we need take a single write lock and disable interrupts > while setting up debugfs. This is what what happens when we try anyway: > > |ccp :03:00.2: enabling device ( -> 0002) > |BUG: sleeping function called from invalid context at > kernel/locking/rwsem.c:69 > |in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0 > |irq event stamp: 17150 > |hardirqs last enabled at (17149): [<97a18c49>] > restore_regs_and_return_to_kernel+0x0/0x23 > |hardirqs last disabled at (17150): [<0773b3a9>] > _raw_write_lock_irqsave+0x1b/0x50 > |softirqs last enabled at (17148): [<64d56155>] > __do_softirq+0x3b8/0x4c1 > |softirqs last disabled at (17125): [<92633c18>] irq_exit+0xb1/0xc0 > |CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30 > |Workqueue: events work_for_cpu_fn > |Call Trace: > | dump_stack+0x7d/0xb6 > | ___might_sleep+0x1eb/0x250 > | down_write+0x17/0x60 > | start_creating+0x4c/0xe0 > | debugfs_create_dir+0x9/0x100 > | ccp5_debugfs_setup+0x191/0x1b0 > | ccp5_init+0x8a7/0x8c0 > | ccp_dev_init+0xb8/0xe0 > | sp_init+0x6c/0x90 > | sp_pci_probe+0x26e/0x590 > | local_pci_probe+0x3f/0x90 > | work_for_cpu_fn+0x11/0x20 > | process_one_work+0x1ff/0x650 > | worker_thread+0x1d4/0x3a0 > | kthread+0xfe/0x130 > | ret_from_fork+0x27/0x50 > > If any locking is required, a simple mutex will do it. > > Cc: Gary R Hook <gary.h...@amd.com> > Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de> 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 0/4] Enable CAAM on i.MX7s fix TrustZone issues
On Thu, Feb 22, 2018 at 02:22:46PM +, Rui Miguel Silva wrote: > For v4 I am taking over this patch series as all the left over patches were > implemented by me. > > V4: > - removed patch: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is > already initialized from the series since Horia presented a better fix for the > endless loop in case of fail to acquire DECO: > 225ece3e7dad4 crypto: caam - fix endless loop when DECO acquire fails > - add Fabio Estevam reviewed by tag in PATCH 3/3. > - removed CAAM ERA from dts since bootloader will add it - Horia. > > V3: > - Added Cc: clk driver maintainers - Fabio Estevam > - Added Cc: i.MX arch maintainers - Fabio Estevam > - Removed bouncing email address for Herbert Xu > > V2-resend: > - Patch 0005 lost in the ether - resending > > V2: > - Endian detection is ok with TrustZone enabled Horia. > Endian detection logic tested with TrustZone enabled. The register that > this relies on though isn't affected by the lock-down in the first page. > Assuming set of affected registers is actually just the 'deco' registers > though there is no formal statement of that, that I am aware of. > > - Moving of TrustZone work-around into u-boot > This set actually doesn't need to deal with TrustZone at all now but, for > the sake of consistency keeping thread title > > https://patchwork.ozlabs.org/patch/866460/ > https://patchwork.ozlabs.org/patch/866462/ > https://patchwork.ozlabs.org/patch/865890/ > > - Reworded endless loop fix to read a bit better > > - Fixes to DTS additions - Rui > > - Fixes to number of clocks declared - Rui > > V1: > This patch-set enables CAAM on the i.MX7s and fixes a number of issues > identified with the CAAM driver and hardware when TrustZone mode is > enabled. > > The first block of patches are simple bug-fixes, followed by a second block > of patches which are simple enabling patches for the i.MX7Solo - note we > aren't enabling for the i.MX7Dual since we don't have hardware to test that > out but it should be a 1:1 mapping for others to enable when appropriate. > > Cheers, > Rui > > Rui Miguel Silva (4): > crypto: caam - Fix null dereference at error path > crypto: caam - do not use mem and emi_slow clock for imx7x > clk: imx7d: add CAAM clock > ARM: dts: imx7s: add CAAM device node > > arch/arm/boot/dts/imx7s.dtsi| 30 +++ > drivers/clk/imx/clk-imx7d.c | 1 + > drivers/crypto/caam/ctrl.c | 42 > +++-- > include/dt-bindings/clock/imx7d-clock.h | 3 ++- > 4 files changed, 57 insertions(+), 19 deletions(-) Patches 1 and 2 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: atmel-aes - fix the keys zeroing on errors
On Fri, Feb 23, 2018 at 10:01:40AM +0100, Antoine Tenart wrote:
> The Atmel AES driver uses memzero_explicit on the keys on error, but the
> variable zeroed isn't the right one because of a typo. Fix this by using
> the right variable.
>
> Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to
> authenc(hmac(shaX), Y(aes)) modes")
> 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] crypto: ccp: add check to get PSP master only when PSP is detected
Brijesh Singh <brijesh.si...@amd.com> wrote: > Paulian reported the below kernel crash on Ryzen 5 system: > > BUG: unable to handle kernel NULL pointer dereference at 0073 > RIP: 0010:.LC0+0x41f/0xa00 > RSP: 0018:a9968003bdd0 EFLAGS: 00010002 > RAX: b113b130 RBX: RCX: 05a7 > RDX: 00ff RSI: 8b46dee651a0 RDI: b1bd617c > RBP: 0246 R08: 000251a0 R09: > R10: d81f11a38200 R11: 8b52e8e0a161 R12: b19db220 > R13: 0007 R14: b17e4888 R15: 5dccd7affc30a31e > FS: () GS:8b46dee4() knlGS: > CR2: 0073 CR3: 80128120a000 CR4: 003406e0 > Call Trace: > ? sp_get_psp_master_device+0x56/0x80 > ? map_properties+0x540/0x540 > ? psp_pci_init+0x20/0xe0 > ? map_properties+0x540/0x540 > ? sp_mod_init+0x16/0x1a > ? do_one_initcall+0x4b/0x190 > ? kernel_init_freeable+0x19b/0x23c > ? rest_init+0xb0/0xb0 > ? kernel_init+0xa/0x100 > ? ret_from_fork+0x22/0x40 > > Since Ryzen does not support PSP/SEV firmware hence i->psp_data will > NULL in all sp instances. In those cases, 'i' will point to the > list head after list_for_each_entry(). Dereferencing the head will > cause kernel crash. > > Add check to call get master device only when PSP/SEV is detected. > > Reported-by: Paulian Bogdan Marinca <paul...@marinca.net> > Cc: Borislav Petkov <b...@suse.de> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > CC: Gary R Hook <gary.h...@amd.com> > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Brijesh Singh <brijesh.si...@amd.com> > --- > > Changes since v1: > > v1 contained a local change I used for triggering the crash on EPYC system. > we do not need those changes in final patch. 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 00/30] crypto: x86 glue code cleanup/conversion
On Mon, Feb 19, 2018 at 11:47:58PM -0800, Eric Biggers wrote: > Hi, > > I got tired of seeing some block cipher implementations using the old > API (blkcipher or ablkcipher) and some using the new API (skcipher)... > so this series makes a dent in the problem by converting all the > remaining x86 glue code over to the skcipher API. > > Besides the conversion to use 'skcipher_alg', 'skcipher_request', and > 'skcipher_walk' this includes replacing all remaining users of > ablk_helper with crypto_simd, then removing ablk_helper. > > It also includes removing all users of lrw_crypt() and xts_crypt() in > favor of the lrw and xts templates wrapping an ECB-mode algorithm. So, > lrw_crypt() and xts_crypt() are removed too. > > Note that AES was already converted a while ago, so this series mostly > just deals with the other ciphers (Serpent, Twofish, Camellia, etc.). > > I tested all the affected algorithms with the self-tests. I also did > some testing with random sglist divisions, during which I found a bug in > ecb-cast5-avx which this series fixes as well. > > The overall diff is about 3100 lines of code removed, mainly due to the > ablk_helper => crypto_simd conversions and removing the unnecessary LRW > and XTS implementations. > > Eric Biggers (30): > 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 > > arch/x86/crypto/blowfish_glue.c| 230 +++-- > arch/x86/crypto/camellia_aesni_avx2_glue.c | 491 ++- > arch/x86/crypto/camellia_aesni_avx_glue.c | 495 +++ > arch/x86/crypto/camellia_glue.c| 356 +--- > arch/x86/crypto/cast5_avx_glue.c | 352 +++ > arch/x86/crypto/cast6_avx_glue.c | 489 ++- > arch/x86/crypto/des3_ede_glue.c| 238 ++--- > arch/x86/crypto/glue_helper.c | 391 +++--- > arch/x86/crypto/serpent_avx2_glue.c| 478 ++ > arch/x86/crypto/serpent_avx_glue.c | 518 +++- > arch/x86/crypto/serpent_sse2_glue.c| 519 > - > arch/x86/crypto/twofish_avx_glue.c | 493 +++ > arch/x86/crypto/twofish_glue_3way.c| 339 --- > arch/x86/include/asm/crypto/camellia.h | 16 +- > arch/x86/include/asm/crypto/glue_helper.h | 75 + > arch/x86/include/asm/crypto/serpent-avx.h | 17 +- > arch/x86/include/asm/crypto/twofish.h | 19 -- > crypto/Kconfig | 82 ++--- > crypto/Makefile| 1 - > crypto/ablk_helper.c | 150 - > crypto/lrw.c | 152 +++-- > crypto/simd.c | 50 +++ > crypto/xts.c | 72 > include/crypto/ablk_helper.h | 32 -- > include/crypto/internal/simd.h | 7 + > include/crypto/lrw.h | 44 --- > include/crypto/xts.h
Re: [PATCH] crypto: marvell/cesa - Clean up redundant #include
On Mon, Feb 19, 2018 at 01:55:36PM +, Robin Murphy wrote: > The inclusion of dma-direct.h was only needed temporarily to prevent > breakage from the DMA API rework, since the actual CESA fix making it > redundant was merged in parallel. Now that both have landed, it can go. > > Signed-off-by: Robin Murphy <robin.mur...@arm.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/4] cleanups and new HW rev support
On Mon, Feb 19, 2018 at 02:51:20PM +, Gilad Ben-Yossef wrote: > This patch set introduces backward compatible support for the older > CryptoCell hardware revision 710 and 630 along some minor code > cleanups. > > Gilad Ben-Yossef (4): > 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 > > .../devicetree/bindings/crypto/arm-cryptocell.txt | 3 +- > drivers/crypto/Kconfig | 6 +- > drivers/crypto/ccree/cc_aead.c | 34 +++-- > drivers/crypto/ccree/cc_cipher.c | 25 +++- > drivers/crypto/ccree/cc_crypto_ctx.h | 36 - > drivers/crypto/ccree/cc_driver.c | 68 -- > drivers/crypto/ccree/cc_driver.h | 23 +++- > drivers/crypto/ccree/cc_fips.c | 13 +- > drivers/crypto/ccree/cc_hash.c | 149 > +++-- > drivers/crypto/ccree/cc_hash.h | 12 +- > drivers/crypto/ccree/cc_host_regs.h| 3 + > drivers/crypto/ccree/cc_hw_queue_defs.h| 2 +- > drivers/crypto/ccree/cc_kernel_regs.h | 1 + > drivers/crypto/ccree/cc_request_mgr.c | 9 +- > drivers/crypto/ccree/cc_sram_mgr.c | 14 ++ > 15 files changed, 240 insertions(+), 158 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 1/2] crypto: ccp: Fix sparse, use plain integer as NULL pointer
On Thu, Feb 15, 2018 at 01:34:44PM -0600, Brijesh Singh wrote: > Fix sparse warning: Using plain integer as NULL pointer. Replaces > assignment of 0 to pointer with NULL assignment. > > Fixes: 200664d5237f (Add Secure Encrypted Virtualization ...) > Cc: Borislav Petkov <b...@suse.de> > Cc: Herbert Xu <herb...@gondor.apana.org.au> > Cc: Gary Hook <gary.h...@amd.com> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Signed-off-by: Brijesh Singh <brijesh.si...@amd.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: [PATCH Resend 0/5] hwrng: stm32 - Improvement for stm32-rng
On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote: > This set of patches add extended functionalities for stm32 rng > driver. > Patch #1 includes a reset during probe to avoid any error status > which can occur during bootup process and keep safe rng integrity. > > Patch #3 adds a new property to manage the clock error detection > feature which can be disabled on specific target. > > Patch #5 rework the timeout calculation for read value that was > previously defined based on loop operation and is now based on > timer. > > Lionel Debieve (5): > hwrng: stm32 - add reset during probe > dt-bindings: rng: add reset node for stm32 > hwrng: stm32 - allow disable clock error detection > dt-bindings: rng: add clock detection error for stm32 > hwrng: stm32 - rework read timeout calculation > > .../devicetree/bindings/rng/st,stm32-rng.txt | 4 ++ > drivers/char/hw_random/stm32-rng.c | 44 > ++ > 2 files changed, 32 insertions(+), 16 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 Resend 0/5] hwrng: stm32 - Improvement for stm32-rng
On Thu, Feb 22, 2018 at 04:25:46PM +0100, Alexandre Torgue wrote: > Hi > > On 02/22/2018 03:03 PM, Herbert Xu wrote: > >On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote: > >>This set of patches add extended functionalities for stm32 rng > >>driver. > >>Patch #1 includes a reset during probe to avoid any error status > >>which can occur during bootup process and keep safe rng integrity. > >> > >>Patch #3 adds a new property to manage the clock error detection > >>feature which can be disabled on specific target. > >> > >>Patch #5 rework the timeout calculation for read value that was > >>previously defined based on loop operation and is now based on > >>timer. > > > >I should take only patches 1/3/5, right? > > You could take all (dt-bindings + drivers part). 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 0/4] crypto: AF_ALG AIO improvements
On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > A simple copy operation, however, will imply that in one AIO recvmsg request, > only *one* IOCB can be set and processed. Sure, but the recvmsg will return as soon as the crypto API encrypt or decrypt function returns. It's still fully async. It's just that the setup part needs to be done with sendmsg/recvmsg. Even if we wanted to do what you stated, just inlining the IV isn't enough. You'd also need to inline the assoclen, and probably the optype in case you want to mix encrypt/decrypt too. However, I must say that I don't see the point of going all the way to support such a bulk submission interface (e.g., lio_listio). Remember, the algif interface due to its inherent overhead is meant for bulk data. That is, the processing time for each request is dominated by the actual processing, not the submission process. If you're instead processing lots of tiny requests, do NOT use algif because it's not designed for that. Therefore spending too much time to optimise the submission overhead seems pointless to me. 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: ixp4xxx: Use dma_pool_zalloc()
On Thu, Feb 22, 2018 at 08:54:27PM +0530, Souptick Joarder wrote: > > Apology, Missed it. Then adding dma_pool_zalloc() not making much difference. > Shall I drop this patch or send v2 ? I think we should probably leave it alone. 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/sahara: Adjustments for sahara_probe()
On Wed, Feb 14, 2018 at 02:32:28PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 14:30:28 +0100 > > Two update suggestions were taken into account > from static source code analysis. > > Markus Elfring (2): > Delete an error message for a failed memory allocation > Improve a size determination > > drivers/crypto/sahara.c | 6 ++ > 1 file changed, 2 insertions(+), 4 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: bfin_crc: Delete an error message for a failed memory allocation in bfin_crypto_crc_probe()
On Wed, Feb 14, 2018 at 09:42:26PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 21:34:54 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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: bcm: Delete an error message for a failed memory allocation in do_shash()
On Wed, Feb 14, 2018 at 10:39:25PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 22:05:11 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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: atmel: Delete error messages for a failed memory allocation in six functions
On Thu, Feb 15, 2018 at 01:24:18PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Thu, 15 Feb 2018 11:38:30 +0100 > > Omit extra messages for a memory allocation failure in these functions. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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: ixp4xxx: Use dma_pool_zalloc()
On Thu, Feb 22, 2018 at 08:32:36PM +0530, Souptick Joarder wrote: > On Thu, Feb 22, 2018 at 7:40 PM, Herbert Xu <herb...@gondor.apana.org.au> > wrote: > > On Sat, Feb 17, 2018 at 03:41:13PM +0530, Souptick Joarder wrote: > >> Use dma_pool_zalloc() instead of dma_pool_alloc + memset > >> > >> Signed-off-by: Souptick Joarder <jrdr.li...@gmail.com> > > > > Hmm, the memset doesn't just happen at allocation time. You haven't > > explained why it is OK to remove the memset at these other points. > > Inside init_sa_dir(), reset_sa_dir() is called immediately after > dma_pool_alloc() > where memset was done for pointer "dir->npe_ctx". Hence removing the memset > is fine inside reset_sa_dir() as dma_pool_zalloc() is already doing it. Yes but reset_sa_dir is also called from other places. 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: fix memdup.cocci warnings
On Fri, Feb 16, 2018 at 12:40:13AM +0800, kbuild test robot wrote:
> From: Fengguang Wu <fengguang...@intel.com>
>
> drivers/crypto/ccree/cc_cipher.c:629:15-22: WARNING opportunity for kmemdep
>
> Use kmemdup rather than duplicating its implementation
>
> Generated by: scripts/coccinelle/api/memdup.cocci
>
> Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
> CC: Gilad Ben-Yossef <gi...@benyossef.com>
> Signed-off-by: Fengguang Wu <fengguang...@intel.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/14] x86/crypto gcmaes SSE scatter/gather support
On Wed, Feb 14, 2018 at 09:37:51AM -0800, Dave Watson wrote: > This patch set refactors the x86 aes/gcm SSE crypto routines to > support true scatter/gather by adding gcm_enc/dec_update methods. > > The layout is: > > * First 5 patches refactor the code to use macros, so changes only > need to be applied once for encode and decode. There should be no > functional changes. > > * The next 6 patches introduce a gcm_context structure to be passed > between scatter/gather calls to maintain state. The struct is also > used as scratch space for the existing enc/dec routines. > > * The last 2 set up the asm function entry points for scatter gather > support, and then call the new routines per buffer in the passed in > sglist in aesni-intel_glue. > > Testing: > asm itself fuzz tested vs. existing code and isa-l asm. > Ran libkcapi test suite, passes. > > perf of a large (16k messages) TLS sends sg vs. no sg: > > no-sg > > 33287255597 cycles > 53702871176 instructions > > 43.47% _crypt_by_4 > 17.83% memcpy > 16.36% aes_loop_par_enc_done > > sg > > 27568944591 cycles > 54580446678 instructions > > 49.87% _crypt_by_4 > 17.40% aes_loop_par_enc_done > 1.79%aes_loop_initial_5416 > 1.52%aes_loop_initial_4974 > 1.27%gcmaes_encrypt_sg.constprop.15 > > V1 -> V2: > > patch 14: merge enc/dec > also use new routine if cryptlen < AVX_GEN2_OPTSIZE > optimize case if assoc is already linear > > Dave Watson (14): > x86/crypto: aesni: Merge INITIAL_BLOCKS_ENC/DEC > x86/crypto: aesni: Macro-ify func save/restore > x86/crypto: aesni: Add GCM_INIT macro > x86/crypto: aesni: Add GCM_COMPLETE macro > x86/crypto: aesni: Merge encode and decode to GCM_ENC_DEC macro > x86/crypto: aesni: Introduce gcm_context_data > x86/crypto: aesni: Split AAD hash calculation to separate macro > x86/crypto: aesni: Fill in new context data structures > x86/crypto: aesni: Move ghash_mul to GCM_COMPLETE > x86/crypto: aesni: Move HashKey computation from stack to gcm_context > x86/crypto: aesni: Introduce partial block macro > x86/crypto: aesni: Add fast path for > 16 byte update > x86/crypto: aesni: Introduce scatter/gather asm function stubs > x86/crypto: aesni: Update aesni-intel_glue to use scatter/gather > > arch/x86/crypto/aesni-intel_asm.S | 1414 > ++-- > arch/x86/crypto/aesni-intel_glue.c | 230 +- > 2 files changed, 899 insertions(+), 745 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: nx-842: Delete an error message for a failed memory allocation in nx842_pseries_init()
On Wed, Feb 14, 2018 at 05:17:08PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 17:05:13 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> 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 0/5] crypto: Speck support
On Wed, Feb 14, 2018 at 10:42:18AM -0800, Eric Biggers wrote: > Hello, > > This series adds Speck support to the crypto API, including the Speck128 > and Speck64 variants. Speck is a lightweight block cipher that can be > much faster than AES on processors that don't have AES instructions. > > We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an > option for dm-crypt and fscrypt on Android, for low-end mobile devices > with older CPUs such as ARMv7 which don't have the Cryptography > Extensions. Currently, such devices are unencrypted because AES is not > fast enough, even when the NEON bit-sliced implementation of AES is > used. Other AES alternatives such as Twofish, Threefish, Camellia, > CAST6, and Serpent aren't fast enough either; it seems that only a > modern ARX cipher can provide sufficient performance on these devices. > > This is a replacement for our original proposal > (https://patchwork.kernel.org/patch/10101451/) which was to offer > ChaCha20 for these devices. However, the use of a stream cipher for > disk/file encryption with no space to store nonces would have been much > more insecure than we thought initially, given that it would be used on > top of flash storage as well as potentially on top of F2FS, neither of > which is guaranteed to overwrite data in-place. > > Speck has been somewhat controversial due to its origin. Nevertheless, > it has a straightforward design (it's an ARX cipher), and it appears to > be the leading software-optimized lightweight block cipher currently, > with the most cryptanalysis. It's also easy to implement without side > channels, unlike AES. Moreover, we only intend Speck to be used when > the status quo is no encryption, due to AES not being fast enough. > > We've also considered a novel length-preserving encryption mode based on > ChaCha20 and Poly1305. While theoretically attractive, such a mode > would be a brand new crypto construction and would be more complicated > and difficult to implement efficiently in comparison to Speck-XTS. > > Thus, patch 1 adds a generic implementation of Speck, and the following > patches add a 32-bit ARM NEON implementation of Speck-XTS. The > NEON-accelerated implementation is much faster than the generic > implementation and therefore is the implementation that would primarily > be used in practice on the devices we are targeting. > > There is no AArch64 implementation included, since most such CPUs have > the Cryptography Extensions, allowing the use of AES. An AArch64 > implementation can be added later if there is interest though. > > Changed since v2: > > - Fix __speck64_xts_crypt() to work on big endian CPUs. > > Changed since v1: > > - Use the word order recommended by the Speck authors. All test > vectors were updated. > > Eric Biggers (5): > crypto: 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 > > arch/arm/crypto/Kconfig |6 + > arch/arm/crypto/Makefile |2 + > arch/arm/crypto/speck-neon-core.S | 432 + > arch/arm/crypto/speck-neon-glue.c | 288 ++ > crypto/Kconfig| 14 + > crypto/Makefile |1 + > crypto/speck.c| 307 ++ > crypto/testmgr.c | 36 + > crypto/testmgr.h | 1486 + > include/crypto/speck.h| 62 ++ > 10 files changed, 2634 insertions(+) > create mode 100644 arch/arm/crypto/speck-neon-core.S > create mode 100644 arch/arm/crypto/speck-neon-glue.c > create mode 100644 crypto/speck.c > create mode 100644 include/crypto/speck.h 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/4] Ux500 crypto: Adjustments for ux500_cryp_probe()
On Wed, Feb 14, 2018 at 11:16:39AM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 11:12:34 +0100 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (4): > Delete an error message for a failed memory allocation > Adjust two condition checks > Adjust an error message > Delete two unnecessary variable initialisations > > drivers/crypto/ux500/cryp/cryp_core.c | 14 +- > 1 file changed, 5 insertions(+), 9 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/8] crypto: inside-secure - stabilization and fixes
On Tue, Feb 13, 2018 at 09:26:49AM +0100, Antoine Tenart wrote: > Hi Herbert, > > We spent a lot of time with Ofer to test various use cases of the Inside > Secure driver. We performed many tests in addition to the crypto > subsystem ones (IPsec, openssl speed, tcrypt...). As a result the driver > is a lot more stable in various configurations, with this series > applied. > > The fixes of this series aren't all related, but were all found while > performing these stabilization process and tests. > > Also as the company I'm working at changed its name from Free Electrons > to Bootlin, the first patch updates my email address in the MAINTAINERS > file. > > The series is based on v4.16-rc1. > > Thanks! > Antoine > > Antoine Tenart (8): > MAINTAINERS: update the Inside Secure maintainer email > crypto: inside-secure - do not overwrite the threshold value > crypto: inside-secure - fix the extra cache computation > crypto: inside-secure - fix the cache_len computation > crypto: inside-secure - do not process request if no command was > issued > crypto: inside-secure - fix the invalidation step during cra_exit > crypto: inside-secure - keep the requests push/pop synced > crypto: inside-secure - unmap the result in the hash send error path > > MAINTAINERS| 2 +- > drivers/crypto/inside-secure/safexcel.c| 40 > +++--- > drivers/crypto/inside-secure/safexcel.h| 6 ++-- > drivers/crypto/inside-secure/safexcel_cipher.c | 2 +- > drivers/crypto/inside-secure/safexcel_hash.c | 10 --- > 5 files changed, 33 insertions(+), 27 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] hwrng: bcm2835: Handle deferred clock properly
On Mon, Feb 12, 2018 at 09:11:36PM +0100, Stefan Wahren wrote:
> In case the probe of the clock is deferred, we would assume it is
> optional. This is wrong, so defer the probe of this driver until
> the clock is available.
>
> Fixes: 791af4f4907a ("hwrng: bcm2835 - Manage an optional clock")
> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.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: arm/aes-cipher - move S-box to .rodata section
On Mon, Feb 12, 2018 at 10:52:37PM +0900, Jinbum Park wrote: > Move the AES inverse S-box to the .rodata section > where it is safe from abuse by speculation. > > Signed-off-by: Jinbum Park <jinb.pa...@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] crypto: sunxi-ss: Add MODULE_ALIAS to sun4i-ss
On Sun, Feb 11, 2018 at 11:15:37PM +, Peter Robinson wrote:
> The MODULE_ALIAS is required to enable the sun4i-ss driver to load
> automatically when built at a module. Tested on a Cubietruck.
>
> Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto
> accelerator")
> Cc: <sta...@vger.kernel.org>
> Signed-off-by: Peter Robinson <pbrobin...@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 v3 0/4] crypto: aesni - Use zero-copy for gcm(aes) buffers that are partially contiguous
On Wed, Jan 31, 2018 at 12:27:18PM -0800, Junaid Shahid wrote: > Changes in v3: > - Rebased on top of the latest linux-next > Changes in v2: > - Integrated https://patchwork.kernel.org/patch/10173981 > > Currently, the AESNI gcm(aes) implementation uses zero-copy only when the > entire src and dest request buffers, including the AAD, the data and the > Auth Tag are contiguous. This series enables the use of zero-copy even if the > AAD and/or Auth Tag are in different buffers than the actual data, as long as > each of them individually satisfies the zero-copy conditions (i.e. the entire > buffer is either in low-mem or within a single high-mem page). Furthermore, > it also enables the use of zero-copy even if only one of src and dest > satisfies > these conditions rather than only when both of them do. > > Junaid Shahid (4): > crypto: aesni - Fix out-of-bounds access of the AAD buffer in AVX > gcm-aesni > crypto: aesni - Enable one-sided zero copy for gcm(aes) request > buffers > crypto: aesni - Directly use kmap_atomic instead of scatter_walk > object in gcm(aes) > crypto: aesni - Use zero-copy for gcm(aes) even if the > AAD/Data/AuthTag are separate > > arch/x86/crypto/aesni-intel_avx-x86_64.S | 154 +--- > arch/x86/crypto/aesni-intel_glue.c | 307 > +++ > 2 files changed, 227 insertions(+), 234 deletions(-) I think this conflicts with Dave Watson's work. Could you rebase this on top of his patches? 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.16
Hi Linus: This push fixes an oops in the s5p-sss driver when used with ecb(aes). Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Kamil Konieczny (1): crypto: s5p-sss - Fix kernel Oops in AES-ECB mode drivers/crypto/s5p-sss.c | 12 +--- 1 file changed, 9 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] crypto: ixp4xxx: Use dma_pool_zalloc()
On Sat, Feb 17, 2018 at 03:41:13PM +0530, Souptick Joarder wrote: > Use dma_pool_zalloc() instead of dma_pool_alloc + memset > > Signed-off-by: Souptick Joarder <jrdr.li...@gmail.com> Hmm, the memset doesn't just happen at allocation time. You haven't explained why it is OK to remove the memset at these other points. 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 0/5] hwrng: stm32 - Improvement for stm32-rng
On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote: > This set of patches add extended functionalities for stm32 rng > driver. > Patch #1 includes a reset during probe to avoid any error status > which can occur during bootup process and keep safe rng integrity. > > Patch #3 adds a new property to manage the clock error detection > feature which can be disabled on specific target. > > Patch #5 rework the timeout calculation for read value that was > previously defined based on loop operation and is now based on > timer. I should take only patches 1/3/5, right? 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 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
On Thu, Feb 22, 2018 at 12:29:28PM +, Horia Geantă wrote: > > IIUC this means that there is no room for improvement. > This patch needs to be reverted, to restore previous behaviour when the > hw_context was mapped / unmapped for every request. In general we should avoid trying to do batching in drivers. Such optimisations should instead be done at a higher level. For example, for disk encryption we want to do the aggregation at the block layer rather than the crypto API because that has innate knowledge of the data layout which we can only guess. 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: bcm: One function call less in do_shash() after error detection
On Wed, Feb 14, 2018 at 10:40:26PM +0100, SF Markus Elfring wrote: > From: Markus Elfring <elfr...@users.sourceforge.net> > Date: Wed, 14 Feb 2018 22:22:20 +0100 > > The kfree() function was called in one case by the do_shash() function > during error handling even if the passed variable contained a null pointer. > > * Reorder two function calls at the end. > > * Add a jump target. This patch is pointless as kfree on NULL is a no-op. 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
