Re: [PATCH] crypto: correct obvious misspelling "cypto-controller"
On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
Adding Rob Herring to the cc list.
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> index 5e2ba385b8c9..53e39d5f94e7 100644
> --- a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> +++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> @@ -16,7 +16,7 @@ Required properties:
>
> Examples:
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0xff8a 0x4000>;
> interrupts = ;
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index d7e49d29ace5..dcfdb2c0d206 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -942,7 +942,7 @@
> status = "disabled";
> };
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0x0 0xff8a 0x0 0x4000>;
> interrupts = ;
>
> rday
>
> --
>
>
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca/dokuwiki
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
>
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: caam - ablkcipher -> skcipher conversion
On Mon, Aug 06, 2018 at 03:43:56PM +0300, Horia Geantă wrote: > This patch set converts caam/jr and caam/qi top level drivers > from ablkcipher API to skcipher. > > First two patches remove the unused ablkcipher algorithms with > support for IV generation. > The following two patches deal with the conversion. > > Note: There is a dependency for the patch set - a fix sent separately: > "crypto: caam/qi - fix error path in xts setkey" > https://patchwork.kernel.org/patch/10557015 > > Horia Geantă (4): > crypto: caam/jr - remove ablkcipher IV generation > crypto: caam/qi - remove ablkcipher IV generation > crypto: caam/jr - ablkcipher -> skcipher conversion > crypto: caam/qi - ablkcipher -> skcipher conversion > > drivers/crypto/caam/caamalg.c | 729 > +++-- > drivers/crypto/caam/caamalg_desc.c | 142 ++-- > drivers/crypto/caam/caamalg_desc.h | 28 +- > drivers/crypto/caam/caamalg_qi.c | 626 ++- > drivers/crypto/caam/compat.h | 1 + > drivers/crypto/caam/qi.h | 1 - > 6 files changed, 449 insertions(+), 1078 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: remove Speck
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote: > These are unused, undesired, and have never actually been used by > anybody. The original authors of this code have changed their mind about > its inclusion. While originally proposed for disk encryption on low-end > devices, the idea was discarded [1] in favor of something else before > that could really get going. Therefore, this patch removes Speck. > > [1] https://marc.info/?l=linux-crypto-vger&m=153359499015659 > > Signed-off-by: Jason A. Donenfeld > Acked-by: Eric Biggers > Cc: sta...@vger.kernel.org > --- > Documentation/filesystems/fscrypt.rst | 10 - > arch/arm/crypto/Kconfig | 6 - > arch/arm/crypto/Makefile | 2 - > arch/arm/crypto/speck-neon-core.S | 434 --- > arch/arm/crypto/speck-neon-glue.c | 288 -- > arch/arm64/crypto/Kconfig | 6 - > arch/arm64/crypto/Makefile| 3 - > arch/arm64/crypto/speck-neon-core.S | 352 > arch/arm64/crypto/speck-neon-glue.c | 282 -- > arch/m68k/configs/amiga_defconfig | 1 - > arch/m68k/configs/apollo_defconfig| 1 - > arch/m68k/configs/atari_defconfig | 1 - > arch/m68k/configs/bvme6000_defconfig | 1 - > arch/m68k/configs/hp300_defconfig | 1 - > arch/m68k/configs/mac_defconfig | 1 - > arch/m68k/configs/multi_defconfig | 1 - > arch/m68k/configs/mvme147_defconfig | 1 - > arch/m68k/configs/mvme16x_defconfig | 1 - > arch/m68k/configs/q40_defconfig | 1 - > arch/m68k/configs/sun3_defconfig | 1 - > arch/m68k/configs/sun3x_defconfig | 1 - > arch/s390/defconfig | 1 - > crypto/Kconfig| 14 - > crypto/Makefile | 1 - > crypto/speck.c| 307 --- > crypto/testmgr.c | 24 - > crypto/testmgr.h | 738 -- > fs/crypto/fscrypt_private.h | 4 - > fs/crypto/keyinfo.c | 10 - > include/crypto/speck.h| 62 --- > include/uapi/linux/fs.h | 4 +- > 31 files changed, 2 insertions(+), 2558 deletions(-) > delete mode 100644 arch/arm/crypto/speck-neon-core.S > delete mode 100644 arch/arm/crypto/speck-neon-glue.c > delete mode 100644 arch/arm64/crypto/speck-neon-core.S > delete mode 100644 arch/arm64/crypto/speck-neon-glue.c > delete mode 100644 crypto/speck.c > delete mode 100644 include/crypto/speck.h Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH crypto-2.6] crypto: ccp: add timeout support in the SEV command
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote: > Currently, the CCP driver assumes that the SEV command issued to the PSP > will always return (i.e. it will never hang). But recently, firmware bugs > have shown that a command can hang. Since of the SEV commands are used > in probe routines, this can cause boot hangs and/or loss of virtualization > capabilities. > > To protect against firmware bugs, add a timeout in the SEV command > execution flow. If a command does not complete within the specified > timeout then return -ETIMEOUT and stop the driver from executing any > further commands since the state of the SEV firmware is unknown. > > Cc: Tom Lendacky > Cc: Gary Hook > Cc: Herbert Xu > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Brijesh Singh > --- > drivers/crypto/ccp/psp-dev.c | 46 > +++- > 1 file changed, 41 insertions(+), 5 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel - switch to SPDX license identifiers
On Tue, Aug 21, 2018 at 04:36:09PM +0300, Tudor Ambarus wrote: > Adopt the SPDX license identifiers to ease license compliance > management. > > Signed-off-by: Tudor Ambarus > --- > drivers/crypto/atmel-aes.c | 5 + > drivers/crypto/atmel-authenc.h | 13 + > drivers/crypto/atmel-ecc.c | 11 +-- > drivers/crypto/atmel-ecc.h | 14 +- > drivers/crypto/atmel-sha.c | 5 + > drivers/crypto/atmel-tdes.c| 5 + > 6 files changed, 6 insertions(+), 47 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector
On Thu, Aug 23, 2018 at 05:48:45PM +0100, Ard Biesheuvel wrote: > Replace the literal load of the addend vector with a sequence that > performs each add individually. This sequence is only 2 instructions > longer than the original, and 2% faster on Cortex-A53. > > This is an improvement by itself, but also works around a Clang issue, > whose integrated assembler does not implement the GNU ARM asm syntax > completely, and does not support the =literal notation for FP registers > (more info at https://bugs.llvm.org/show_bug.cgi?id=38642) > > Cc: Nick Desaulniers > Signed-off-by: Ard Biesheuvel > --- > v2: replace convoluted code involving a SIMD add to increment four BE counters > at once with individual add/rev/mov instructions > > arch/arm64/crypto/aes-modes.S | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/ghash-ce - implement support for 4-way aggregation
On Thu, Aug 23, 2018 at 03:48:51PM +0100, Ard Biesheuvel wrote: > Speed up the GHASH algorithm based on 64-bit polynomial multiplication > by adding support for 4-way aggregation. This improves throughput by > ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte. > > When combined with AES into GCM, throughput improves by ~25%, from > 3.8 cycles per byte to 3.0 cycles per byte. > > Signed-off-by: Ard Biesheuvel > --- > v2: modulo schedule the loads of the input > add AES/GCM performance numbers to commit log > > arch/arm/crypto/Kconfig | 1 + > arch/arm/crypto/ghash-ce-core.S | 108 +++- > arch/arm/crypto/ghash-ce-glue.c | 38 +-- > 3 files changed, 131 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v8 0/9] crypto: Remove VLA usage
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote: > v8 cover letter: > > I continue to hope this can land in v4.19, but I realize that's unlikely. > It would be nice, though, if some of the "trivial" patches could get taken > (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them. > *fingers crossed* > > Series cover letter: > > This is nearly the last of the VLA removals[1], but it's one of the > largest because crypto gets used in lots of places. After looking > through code, usage, reading the threads Gustavo started, and comparing > the use-cases to the other VLA removals that have landed in the kernel, > I think this series is likely the best way forward to shut the door on > VLAs forever. > > For background, the crypto stack usage is for callers to do an immediate > bit of work that doesn't allocate new memory. This means that other VLA > removal techniques (like just using kmalloc) aren't workable, and the > next common technique is needed: examination of maximum stack usage and > the addition of sanity checks. This series does that, and in several > cases, these maximums were already implicit in the code. > > This series is intended to land via the crypto tree for 4.19, though it > touches dm, networking, and a few other things as well, since there are > dependent patches (new crypto #defines being used, etc). I have applied patches 1-4 and 6-8. I'd like to get an ack from the dm folks regarding patch 5. As to patch 9, please fix it so it doesn't rely on the BUG_ON to catch things. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86 - remove SHA multibuffer routines and mcryptd
On Wed, Aug 22, 2018 at 10:51:44AM +0200, Ard Biesheuvel wrote: > As it turns out, the AVX2 multibuffer SHA routines are currently > broken [0], in a way that would have likely been noticed if this > code were in wide use. Since the code is too complicated to be > maintained by anyone except the original authors, and since the > performance benefits for real-world use cases are debatable to > begin with, it is better to drop it entirely for the moment. > > [0] https://marc.info/?l=linux-crypto-vger&m=153476243825350&w=2 > > Suggested-by: Eric Biggers > Cc: Megha Dey > Cc: Tim Chen > Cc: Geert Uytterhoeven > Cc: Martin Schwidefsky > Cc: Heiko Carstens > Cc: Thomas Gleixner > Cc: Ingo Molnar > Signed-off-by: Ard Biesheuvel > --- > MAINTAINERS |8 - > arch/m68k/configs/amiga_defconfig |1 - > arch/m68k/configs/apollo_defconfig|1 - > arch/m68k/configs/atari_defconfig |1 - > arch/m68k/configs/bvme6000_defconfig |1 - > arch/m68k/configs/hp300_defconfig |1 - > arch/m68k/configs/mac_defconfig |1 - > arch/m68k/configs/multi_defconfig |1 - > arch/m68k/configs/mvme147_defconfig |1 - > arch/m68k/configs/mvme16x_defconfig |1 - > arch/m68k/configs/q40_defconfig |1 - > arch/m68k/configs/sun3_defconfig |1 - > arch/m68k/configs/sun3x_defconfig |1 - > arch/s390/configs/debug_defconfig |1 - > arch/s390/configs/performance_defconfig |1 - > arch/x86/crypto/Makefile |3 - > arch/x86/crypto/sha1-mb/Makefile | 14 - > arch/x86/crypto/sha1-mb/sha1_mb.c | 1011 > arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 134 --- > arch/x86/crypto/sha1-mb/sha1_mb_mgr.h | 110 -- > .../crypto/sha1-mb/sha1_mb_mgr_datastruct.S | 287 - > .../crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 304 - > .../crypto/sha1-mb/sha1_mb_mgr_init_avx2.c| 64 - > .../crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S | 209 > arch/x86/crypto/sha1-mb/sha1_x8_avx2.S| 492 > arch/x86/crypto/sha256-mb/Makefile| 14 - > arch/x86/crypto/sha256-mb/sha256_mb.c | 1013 > arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 134 --- > arch/x86/crypto/sha256-mb/sha256_mb_mgr.h | 108 -- > .../sha256-mb/sha256_mb_mgr_datastruct.S | 304 - > .../sha256-mb/sha256_mb_mgr_flush_avx2.S | 307 - > .../sha256-mb/sha256_mb_mgr_init_avx2.c | 65 - > .../sha256-mb/sha256_mb_mgr_submit_avx2.S | 214 > arch/x86/crypto/sha256-mb/sha256_x8_avx2.S| 598 -- > arch/x86/crypto/sha512-mb/Makefile| 12 - > arch/x86/crypto/sha512-mb/sha512_mb.c | 1047 - > arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 128 -- > arch/x86/crypto/sha512-mb/sha512_mb_mgr.h | 104 -- > .../sha512-mb/sha512_mb_mgr_datastruct.S | 281 - > .../sha512-mb/sha512_mb_mgr_flush_avx2.S | 297 - > .../sha512-mb/sha512_mb_mgr_init_avx2.c | 69 -- > .../sha512-mb/sha512_mb_mgr_submit_avx2.S | 224 > arch/x86/crypto/sha512-mb/sha512_x4_avx2.S| 531 - > crypto/Kconfig| 62 - > crypto/Makefile |1 - > crypto/mcryptd.c | 675 --- > include/crypto/mcryptd.h | 114 -- > 47 files changed, 8952 deletions(-) > delete mode 100644 arch/x86/crypto/sha1-mb/Makefile > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb.c > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_ctx.h > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr.h > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_datastruct.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_init_avx2.c > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_mb_mgr_submit_avx2.S > delete mode 100644 arch/x86/crypto/sha1-mb/sha1_x8_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/Makefile > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb.c > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_ctx.h > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr.h > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_datastruct.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_init_avx2.c > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S > delete mode 100644 arch/x86/crypto/sha512-mb/Makefile > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb.c > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_ct
Re: [PATCH 4/4] crypto: arm64/crc32 - remove PMULL based CRC32 driver
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote: > Now that the scalar fallbacks have been moved out of this driver into > the core crc32()/crc32c() routines, we are left with a CRC32 crypto API > driver for arm64 that is based only on 64x64 polynomial multiplication, > which is an optional instruction in the ARMv8 architecture, and is less > and less likely to be available on cores that do not also implement the > CRC32 instructions, given that those are mandatory in the architecture > as of ARMv8.1. > > Since the scalar instructions do not require the special handling that > SIMD instructions do, and since they turn out to be considerably faster > on some cores (Cortex-A53) as well, there is really no point in keeping > this code around so let's just remove it. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: arm64/crct10dif - refactor and implement non-Crypto Extension version
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote: > The current arm64 CRC-T10DIF code only runs on cores that implement the > 64x64 bit PMULL instructions that are part of the optional Crypto > Extensions, and falls back to the highly inefficient C code otherwise. > > Let's provide a SIMD version that is twice as fast as the C code even on > a low end core like the Cortex-A53, and is time invariant and much easier > on the D-cache. > > Some performance numbers at the bottom. > > Ard Biesheuvel (2): > crypto: arm64/crct10dif - preparatory refactor for 8x8 PMULL version > crypto: arm64/crct10dif - implement non-Crypto Extensions alternative > > arch/arm64/crypto/crct10dif-ce-core.S | 314 +++- > arch/arm64/crypto/crct10dif-ce-glue.c | 14 +- > 2 files changed, 251 insertions(+), 77 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/3] crypto: Introduce notifier for new crypto algorithms
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote: > Introduce a facility that can be used to receive a notification > callback when a new algorithm becomes available. This can be used by > existing crypto registrations to trigger a switch from a software-only > algorithm to a hardware-accelerated version. > > A new CRYPTO_MSG_ALG_LOADED state is introduced to the existing crypto > notification chain, and the register/unregister functions are exported > so they can be called by subsystems outside of crypto. > > Signed-off-by: Martin K. Petersen > Suggested-by: Herbert Xu > --- > crypto/algapi.c | 2 ++ > crypto/algboss.c| 2 ++ > crypto/internal.h | 8 > include/crypto/algapi.h | 10 ++ > 4 files changed, 14 insertions(+), 8 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/chacha20 - faster 8-bit rotations and other optimizations
On Sat, Sep 01, 2018 at 12:17:07AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Optimize ChaCha20 NEON performance by: > > - Implementing the 8-bit rotations using the 'vtbl.8' instruction. > - Streamlining the part that adds the original state and XORs the data. > - Making some other small tweaks. > > On ARM Cortex-A7, these optimizations improve ChaCha20 performance from > about 12.08 cycles per byte to about 11.37 -- a 5.9% improvement. > > There is a tradeoff involved with the 'vtbl.8' rotation method since > there is at least one CPU (Cortex-A53) where it's not fastest. But it > seems to be a better default; see the added comment. Overall, this > patch reduces Cortex-A53 performance by less than 0.5%. > > Signed-off-by: Eric Biggers > --- > arch/arm/crypto/chacha20-neon-core.S | 277 ++- > 1 file changed, 143 insertions(+), 134 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Question about pe file verification
Hi,
Some code logic I don't understand about the function pefile_digest_pe_contents
in the file crypto/asymmetric_keys/verify_pefile.c.
At the end of pefile_digest_pe_contents, please see the comment [sxw] below:
static int pefile_digest_pe_contents(const void *pebuf, unsigned int pelen,
struct pefile_context *ctx,
struct shash_desc *desc)
{
unsigned *canon, tmp, loop, i, hashed_bytes;
int ret;
..
[sxw] I assume the image has signed by sbsign tool, there is a certificate
at the end of image file.
if (pelen > hashed_bytes) {
tmp = hashed_bytes + ctx->certs_size;
[sxw] The tmp value is the end of certificate.
ret = crypto_shash_update(desc,
pebuf + hashed_bytes,
[sxw] The data address is the beginning of the
certificate.
Why do we need to hash the
certification data block?
pelen - tmp);
[sxw] However, the data length doesn't include
the certificate,
sometimes it's zero.
if (ret < 0)
return ret;
}
return 0;
}
Is that for a special consider or something else?
Regards,
Xiongwei
[PATCH] crypto: xts - Drop use of auxiliary buffer
Hi Herbert, Mikulas,
I noticed the discussion about using kmalloc() inside crypto code and it
made me wonder if the code in xts.c can actually be simplified to not
require kmalloc() at all, while not badly affecting performace. I played
around with it a little and it turns out we can drop the whole caching
of tweak blocks, reducing code size by ~200 lines and not only preserve,
but even improve the performance in some cases. See the full patch
below.
Obviously, this doesn't solve the general issue of using kmalloc() in
crypto API routines, but it does resolve the original reported problem
and also makes the XTS code easier to maintain.
Regards,
Ondrej
->8-
Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
caching the computed XTS tweaks has only negligible advantage over
computing them twice.
In fact, since the current caching implementation limits the size of
the calls to the child ecb(...) algorithm to PAGE_SIZE (usually 4096 B),
it is often actually slower than the simple recomputing implementation.
This patch simplifies the XTS template to recompute the XTS tweaks from
scratch in the second pass and thus also removes the need to allocate a
dynamic buffer using kmalloc().
As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.
PERFORMANCE RESULTS
I measured time to encrypt/decrypt a memory buffer of varying sizes with
xts(ecb-aes-aesni) using a tool I wrote ([2]) and the results suggest
that after this patch the performance is either better or comparable for
both small and large buffers. Note that there is a lot of noise in the
measurements, but the overall difference is easy to see.
Old code:
ALGORITHM KEY (b) DATA (B)TIME ENC (ns) TIME DEC (ns)
xts(aes) 256 64 331 328
xts(aes) 384 64 332 333
xts(aes) 512 64 338 348
xts(aes) 256 512 889 920
xts(aes) 384 5121019 993
xts(aes) 512 5121032 990
xts(aes) 256409621522292
xts(aes) 384409624532597
xts(aes) 512409630412641
xts(aes) 256 1638494438027
xts(aes) 384 1638485368925
xts(aes) 512 1638492329417
xts(aes) 256 32768 16383 14897
xts(aes) 384 32768 17527 16102
xts(aes) 512 32768 18483 17322
New code:
ALGORITHM KEY (b) DATA (B)TIME ENC (ns) TIME DEC (ns)
xts(aes) 256 64 328 324
xts(aes) 384 64 324 319
xts(aes) 512 64 320 322
xts(aes) 256 512 476 473
xts(aes) 384 512 509 492
xts(aes) 512 512 531 514
xts(aes) 256409621321829
xts(aes) 384409623572055
xts(aes) 512409621782027
xts(aes) 256 1638469206983
xts(aes) 384 1638485977505
xts(aes) 512 1638478418164
xts(aes) 256 32768 13468 12307
xts(aes) 384 32768 14808 13402
xts(aes) 512 32768 15753 14636
[1] https://lkml.org/lkml/2018/8/23/1315
[2] https://gitlab.com/omos/linux-crypto-bench
Cc: Mikulas Patocka
Signed-off-by: Ondrej Mosnacek
---
crypto/xts.c | 258 ++-
1 file changed, 30 insertions(+), 228 deletions(-)
diff --git a/crypto/xts.c b/crypto/xts.c
index 12284183bd20..6c49e76df8ca 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -26,8 +26,6 @@
#include
#include
-#define XTS_BUFFER_SIZE 128u
-
struct priv {
struct crypto_skcipher *child;
struct crypto_cipher *tweak;
@@ -39,19 +37,7 @@ struct xts_instance_ctx {
};
struct rctx {
- le128 buf[XTS_BUFFER_SIZE / sizeof(le128)];
-
le128 t;
-
- le128 *ext;
-
- struct scatterlist srcbuf[2];
- struct scatterlist dstbuf[2];
- struct scatterlist *src;
- struct scatterlist *dst;
-
- unsigned int left;
-
struct skcip
[PATCH v2 1/2] crypto: Implement a generic crypto statistics
This patch implement a generic way to get statistics about all crypto
usages.
Signed-off-by: Corentin Labbe
---
crypto/Kconfig | 11 +
crypto/Makefile | 1 +
crypto/ahash.c | 21 +-
crypto/algapi.c | 8 +
crypto/{crypto_user.c => crypto_user_base.c} | 9 +-
crypto/crypto_user_stat.c| 463 +++
crypto/rng.c | 1 +
include/crypto/acompress.h | 38 ++-
include/crypto/aead.h| 51 ++-
include/crypto/akcipher.h| 76 -
include/crypto/hash.h| 32 +-
include/crypto/internal/cryptouser.h | 8 +
include/crypto/kpp.h | 51 ++-
include/crypto/rng.h | 29 +-
include/crypto/skcipher.h| 44 ++-
include/linux/crypto.h | 83 -
include/uapi/linux/cryptouser.h | 52 +++
17 files changed, 943 insertions(+), 35 deletions(-)
rename crypto/{crypto_user.c => crypto_user_base.c} (97%)
create mode 100644 crypto/crypto_user_stat.c
create mode 100644 include/crypto/internal/cryptouser.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index f3e40ac56d93..517bd6f4ae20 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1875,6 +1875,17 @@ config CRYPTO_USER_API_AEAD
This option enables the user-spaces interface for AEAD
cipher algorithms.
+config CRYPTO_STATS
+ bool "Crypto usage statistics for User-space"
+ help
+ This option enables the gathering of crypto stats.
+ This will collect:
+ - encrypt/decrypt size and numbers of symmeric operations
+ - compress/decompress size and numbers of compress operations
+ - size and numbers of hash operations
+ - encrypt/decrypt/sign/verify numbers for asymmetric operations
+ - generate/seed numbers for rng operations
+
config CRYPTO_HASH_INFO
bool
diff --git a/crypto/Makefile b/crypto/Makefile
index 6d1d40eeb964..f4282aeabcb6 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -54,6 +54,7 @@ cryptomgr-y := algboss.o testmgr.o
obj-$(CONFIG_CRYPTO_MANAGER2) += cryptomgr.o
obj-$(CONFIG_CRYPTO_USER) += crypto_user.o
+crypto_user-y := crypto_user_base.o crypto_user_stat.o
obj-$(CONFIG_CRYPTO_CMAC) += cmac.o
obj-$(CONFIG_CRYPTO_HMAC) += hmac.o
obj-$(CONFIG_CRYPTO_VMAC) += vmac.o
diff --git a/crypto/ahash.c b/crypto/ahash.c
index a64c143165b1..cecff282c303 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -364,24 +364,35 @@ static int crypto_ahash_op(struct ahash_request *req,
int crypto_ahash_final(struct ahash_request *req)
{
- return crypto_ahash_op(req, crypto_ahash_reqtfm(req)->final);
+ int ret;
+
+ ret = crypto_ahash_op(req, crypto_ahash_reqtfm(req)->final);
+ crypto_stat_ahash_final(req, ret);
+ return ret;
}
EXPORT_SYMBOL_GPL(crypto_ahash_final);
int crypto_ahash_finup(struct ahash_request *req)
{
- return crypto_ahash_op(req, crypto_ahash_reqtfm(req)->finup);
+ int ret;
+
+ ret = crypto_ahash_op(req, crypto_ahash_reqtfm(req)->finup);
+ crypto_stat_ahash_final(req, ret);
+ return ret;
}
EXPORT_SYMBOL_GPL(crypto_ahash_finup);
int crypto_ahash_digest(struct ahash_request *req)
{
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
+ int ret;
if (crypto_ahash_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
- return -ENOKEY;
-
- return crypto_ahash_op(req, tfm->digest);
+ ret = -ENOKEY;
+ else
+ ret = crypto_ahash_op(req, tfm->digest);
+ crypto_stat_ahash_final(req, ret);
+ return ret;
}
EXPORT_SYMBOL_GPL(crypto_ahash_digest);
diff --git a/crypto/algapi.c b/crypto/algapi.c
index c0755cf4f53f..f707ff8ae9ef 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -253,6 +253,14 @@ static struct crypto_larval *__crypto_register_alg(struct
crypto_alg *alg)
list_add(&alg->cra_list, &crypto_alg_list);
list_add(&larval->alg.cra_list, &crypto_alg_list);
+ atomic_set(&alg->encrypt_cnt, 0);
+ atomic_set(&alg->decrypt_cnt, 0);
+ atomic64_set(&alg->encrypt_tlen, 0);
+ atomic64_set(&alg->decrypt_tlen, 0);
+ atomic_set(&alg->verify_cnt, 0);
+ atomic_set(&alg->cipher_err_cnt, 0);
+ atomic_set(&alg->sign_cnt, 0);
+
out:
return larval;
diff --git a/crypto/crypto_user.c b/crypto/crypto_user_base.c
similarity index 97%
rename from crypto/crypto_user.c
rename to crypto/crypto_user_base.c
index 0e89b5457cab..e41f6cc33fff 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user_base.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -37,7 +38,7 @@
static DEFINE_MUTEX(crypto_cfg_mutex);
/* The crypto netlink socket */
-static
[PATCH v2 2/2] crypto: tools: Add cryptostat userspace
This patch add a userspace tool for displaying kernel crypto API
statistics.
Signed-off-by: Corentin Labbe
---
tools/crypto/getstat.c | 294 +
1 file changed, 294 insertions(+)
create mode 100644 tools/crypto/getstat.c
diff --git a/tools/crypto/getstat.c b/tools/crypto/getstat.c
new file mode 100644
index ..994b8e1db8c9
--- /dev/null
+++ b/tools/crypto/getstat.c
@@ -0,0 +1,294 @@
+/* Heavily copied from libkcapi 2015 - 2017, Stephan Mueller
*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CR_RTA(x) ((struct rtattr *)(((char *)(x)) +
NLMSG_ALIGN(sizeof(struct crypto_user_alg
+
+static int get_stat(const char *drivername)
+{
+ struct {
+ struct nlmsghdr n;
+ struct crypto_user_alg cru;
+ } req;
+ struct sockaddr_nl nl;
+ int sd = 0, ret;
+ socklen_t addr_len;
+ struct iovec iov;
+ struct msghdr msg;
+ char buf[4096];
+ struct nlmsghdr *res_n = (struct nlmsghdr *)buf;
+ struct crypto_user_alg *cru_res = NULL;
+ int res_len = 0;
+ struct rtattr *tb[CRYPTOCFGA_MAX + 1];
+ struct rtattr *rta;
+ struct nlmsgerr *errmsg;
+
+ memset(&req, 0, sizeof(req));
+ memset(&buf, 0, sizeof(buf));
+ memset(&msg, 0, sizeof(msg));
+
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(req.cru));
+ req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_type = CRYPTO_MSG_GETSTAT;
+ req.n.nlmsg_seq = time(NULL);
+
+ strncpy(req.cru.cru_driver_name, drivername, strlen(drivername));
+
+ sd = socket(AF_NETLINK, SOCK_RAW, NETLINK_CRYPTO);
+ if (sd < 0) {
+ fprintf(stderr, "Netlink error: cannot open netlink socket");
+ return -errno;
+ }
+ memset(&nl, 0, sizeof(nl));
+ nl.nl_family = AF_NETLINK;
+ if (bind(sd, (struct sockaddr *)&nl, sizeof(nl)) < 0) {
+ ret = -errno;
+ fprintf(stderr, "Netlink error: cannot bind netlink socket");
+ goto out;
+ }
+
+ /* sanity check that netlink socket was successfully opened */
+ addr_len = sizeof(nl);
+ if (getsockname(sd, (struct sockaddr *)&nl, &addr_len) < 0) {
+ ret = -errno;
+ printf("Netlink error: cannot getsockname");
+ goto out;
+ }
+ if (addr_len != sizeof(nl)) {
+ ret = -errno;
+ printf("Netlink error: wrong address length %d", addr_len);
+ goto out;
+ }
+ if (nl.nl_family != AF_NETLINK) {
+ ret = -errno;
+ printf("Netlink error: wrong address family %d",
+ nl.nl_family);
+ goto out;
+ }
+
+ memset(&nl, 0, sizeof(nl));
+ nl.nl_family = AF_NETLINK;
+ iov.iov_base = (void *)&req.n;
+ iov.iov_len = req.n.nlmsg_len;
+ msg.msg_name = &nl;
+ msg.msg_namelen = sizeof(nl);
+ msg.msg_iov = &iov;
+ msg.msg_iovlen = 1;
+ if (sendmsg(sd, &msg, 0) < 0) {
+ ret = -errno;
+ printf("Netlink error: sendmsg failed");
+ goto out;
+ }
+ memset(buf, 0, sizeof(buf));
+ iov.iov_base = buf;
+ while (1) {
+ iov.iov_len = sizeof(buf);
+ ret = recvmsg(sd, &msg, 0);
+ if (ret < 0) {
+ if (errno == EINTR || errno == EAGAIN)
+ continue;
+ ret = -errno;
+ printf("Netlink error: netlink receive error");
+ goto out;
+ }
+ if (ret == 0) {
+ ret = -errno;
+ printf("Netlink error: no data");
+ goto out;
+ }
+ if (ret > sizeof(buf)) {
+ ret = -errno;
+ printf("Netlink error: received too much data");
+ goto out;
+ }
+ break;
+ }
+
+ ret = -EFAULT;
+ res_len = res_n->nlmsg_len;
+ if (res_n->nlmsg_type == NLMSG_ERROR) {
+ errmsg = NLMSG_DATA(res_n);
+ fprintf(stderr, "Fail with %d\n", errmsg->error);
+ ret = errmsg->error;
+ goto out;
+ }
+
+ if (res_n->nlmsg_type == CRYPTO_MSG_GETSTAT) {
+ cru_res = NLMSG_DATA(res_n);
+ res_len -= NLMSG_SPACE(sizeof(*cru_res));
+ }
+ if (res_len < 0) {
+ printf("Netlink error: nlmsg len %d\n", res_len);
+ goto out;
+ }
+
+ if (!cru_res) {
+ ret = -EFAULT;
+ printf("Netlink error: no cru_res\n");
+ goto out;
+ }
+
+ rta = CR_RTA(cru_res);
+ memset(tb, 0, sizeof(struct rtattr
[PATCH v2 0/2] crypto: Implement a generic crypto statistics
This patch is a try to implement a generic crypto driver statistics. The goal is to have an "ifconfig" for crypto device. Some driver tried to implement this via a debugfs interface. This serie do it directly in the crypto API and give access to stats via the crypto_user(netlink) API. Then an userspace tool will collect information via netlink. Note that this userspace tool is heavily copied from libkcapi and if Stephan Mueller agree, I will made a PR for adding getstat to it unless tools/crypto is the good place for it. Example of output: pkcs1pad(rsa-sun8i-ce,sha1) Akcipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Sign: 0 Verify: 5 Errors: 0 cryptd(__xts-aes-ce)cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 xts-aes-ce cipher Encrypt: 17 bytes: 4384 Decrypt: 17 bytes: 4384 Errors: 0 cryptd(__ctr-aes-ce)cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 ctr-aes-ce cipher Encrypt: 19 bytes: 5551 Decrypt: 19 bytes: 5551 Errors: 0 cryptd(__cbc-aes-ce)cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 cbc-aes-ce cipher Encrypt: 19 bytes: 3040 Decrypt: 19 bytes: 3040 Errors: 0 cryptd(__ecb-aes-ce)cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 ecb-aes-ce cipher Encrypt: 14 bytes: 2624 Decrypt: 14 bytes: 2624 Errors: 0 cbcmac-aes-ce Hash Hash: 20 bytes: 1244 Errors: 0 xcbc-aes-ce Hash Hash: 28 bytes: 543 Errors: 0 cmac-aes-ce Hash Hash: 36 bytes: 1472 Errors: 0 __xts-aes-cecipher Encrypt: 17 bytes: 4384 Decrypt: 17 bytes: 4384 Errors: 0 ctr-aes-ce cipher Encrypt: 19 bytes: 5551 Decrypt: 19 bytes: 5551 Errors: 0 __ctr-aes-cecipher Encrypt: 19 bytes: 5551 Decrypt: 19 bytes: 5551 Errors: 0 __cbc-aes-cecipher Encrypt: 19 bytes: 3040 Decrypt: 19 bytes: 3040 Errors: 0 __ecb-aes-cecipher Encrypt: 14 bytes: 2624 Decrypt: 14 bytes: 2624 Errors: 0 rsa-sun8i-ceAkcipher Encrypt: 7 bytes: 232 Decrypt: 6 bytes: 1152 Sign: 0 Verify: 5 Errors: 0 sun8i_ce_rngRNG Seed: 0 Generate: 0 bytes: 0 Errors: 0 ecb(des3_ede-generic) cipher Encrypt: 24 bytes: 4584 Decrypt: 24 bytes: 4584 Errors: 0 ecb-des3-sun8i-ce cipher Encrypt: 18 bytes: 3072 Decrypt: 18 bytes: 3072 Errors: 0 cbc(des3_ede-generic) cipher Encrypt: 14 bytes: 5104 Decrypt: 14 bytes: 5104 Errors: 0 aes-ce cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 des3_ede-genericcipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 des-generic cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 aes-arm64 cipher Encrypt: 0 bytes: 0 Decrypt: 0 bytes: 0 Errors: 0 crc32c-arm64-ce Hash Hash: 92 bytes: 20649 Errors: 0 cbc-des3-sun8i-ce cipher Encrypt: 10 bytes: 3488 Decrypt: 10 bytes: 3488 Errors: 0 crc32-arm64-ce Hash Hash: 92 bytes: 20649 Errors: 0 ecb-aes-sun8i-cecipher Encrypt: 18 bytes: 3168 Decrypt: 18 bytes: 3168 Errors: 0 cbc-aes-sun8i-cecipher Encrypt: 24 bytes: 3712 Decrypt: 24 bytes: 3712 Errors: 0 sha256-ce Hash Hash: 26 bytes: 8860 Errors: 0 sha224-ce Hash Hash: 26 bytes: 8860 Errors: 0 cts(cbc-aes-sun8i-ce) cipher Encrypt: 24 bytes: 956 Decrypt: 24 bytes: 956 Errors: 0 sha224-arm64-neon Hash Hash: 26 bytes: 8860 Errors: 0 sha256-arm64-neon Hash Hash: 26 bytes: 8860 Errors: 0 sha224-arm64Hash Hash: 26 bytes: 8860 Errors: 0 sha256-arm64Hash Hash: 26 bytes: 8860 Errors: 0 ctr-aes-sun8i-cecipher Encrypt: 24 bytes: 6738 Decrypt: 24 bytes: 6738 Errors: 0 sha1-ce Hash Hash: 28 bytes: 9191 Errors: 0 ecdh-genericKPP Setsecret: 4 Generate public key: 3 Compute_shared_secret: 4 Errors: 0 ghash-generic Hash Hash: 32 bytes: 4358 Errors: 0 jitterentropy_rng RNG Seed: 0 Generate: 1 bytes: 48 Errors: 0 drbg_nopr_hmac_sha256 RNG Seed: 5 Generate: 9 bytes: 1056 Errors: 0 drbg_nopr_hmac_sha512 RNG Seed: 0 Generate: 0 bytes: 0 Errors: 0 drbg_nopr_hmac_sha384 RNG Seed: 0 Generate: 0 bytes: 0 Errors: 0 drbg_nopr_hmac_sha1 RNG Seed:
Re: [PATCH v8 5/9] dm: Remove VLA usage from hashes
On Tue, Aug 07, 2018 at 02:18:39PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this uses > the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper > bounds on stack usage. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Kees Cook Can the dm folks please review this patch? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v8 9/9] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK
On Tue, Aug 07, 2018 at 02:18:43PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> caps the skcipher request size similar to other limits and adds a sanity
> check at registration. Looking at instrumented tcrypt output, the largest
> is for lrw:
>
> crypt: testing lrw(aes)
> crypto_skcipher_set_reqsize: 8
> crypto_skcipher_set_reqsize: 88
> crypto_skcipher_set_reqsize: 472
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook
> ---
> include/crypto/internal/skcipher.h | 1 +
> include/crypto/skcipher.h | 4 +++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/crypto/internal/skcipher.h
> b/include/crypto/internal/skcipher.h
> index e42f7063f245..5035482cbe68 100644
> --- a/include/crypto/internal/skcipher.h
> +++ b/include/crypto/internal/skcipher.h
> @@ -130,6 +130,7 @@ static inline struct crypto_skcipher
> *crypto_spawn_skcipher(
> static inline void crypto_skcipher_set_reqsize(
> struct crypto_skcipher *skcipher, unsigned int reqsize)
> {
> + BUG_ON(reqsize > SKCIPHER_MAX_REQSIZE);
Please do not add these BUG_ONs. Instead allow this function to
fail and check for the failure in the caller.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86 - remove SHA multibuffer routines and mcryptd
On Mon, Aug 27, 2018 at 04:19:53PM -0700, Megha Dey wrote: > On Mon, 2018-08-27 at 15:28 -0700, Tim Chen wrote: > > On 08/22/2018 01:51 AM, Ard Biesheuvel wrote: > > > As it turns out, the AVX2 multibuffer SHA routines are currently > > > broken [0], in a way that would have likely been noticed if this > > > code were in wide use. Since the code is too complicated to be > > > maintained by anyone except the original authors, and since the > > > performance benefits for real-world use cases are debatable to > > > begin with, it is better to drop it entirely for the moment. > > > > > > [0] https://marc.info/?l=linux-crypto-vger&m=153476243825350&w=2 > > > > Sorry I was out of the loop for a while and haven't been following > > the code too closely. > > > > Megha is maintaining the code now. Before we pull the code, > > please give us a chance to fix it first. > > > > Thanks. > > > > Tim > > > > Hi, > > I am working to find a fix for these corner cases. If possible, we would > like to fix the issues instead of removing the code altogether. I think it has taken way too long to fix these issues. The fact that these issues have existed for so long also means that hardly anyone uses these mb algorithms. So I think it is best if we remove everything and then add them back after a proper review process. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/4] arm64: cpufeature: add feature for CRC32 instructions
On Tue, Aug 28, 2018 at 08:43:35PM +0200, Ard Biesheuvel wrote: > On 28 August 2018 at 19:01, Will Deacon wrote: > > On Mon, Aug 27, 2018 at 01:02:43PM +0200, Ard Biesheuvel wrote: > >> Add a CRC32 feature bit and wire it up to the CPU id register so we > >> will be able to use alternatives patching for CRC32 operations. > >> > >> Signed-off-by: Ard Biesheuvel > >> --- > >> arch/arm64/include/asm/cpucaps.h | 3 ++- > >> arch/arm64/kernel/cpufeature.c | 9 + > >> 2 files changed, 11 insertions(+), 1 deletion(-) > > > > Acked-by: Will Deacon > > > > With the minor caveat below... > > > >> diff --git a/arch/arm64/include/asm/cpucaps.h > >> b/arch/arm64/include/asm/cpucaps.h > >> index ae1f70450fb2..9932aca9704b 100644 > >> --- a/arch/arm64/include/asm/cpucaps.h > >> +++ b/arch/arm64/include/asm/cpucaps.h > >> @@ -51,7 +51,8 @@ > >> #define ARM64_SSBD 30 > >> #define ARM64_MISMATCHED_CACHE_TYPE 31 > >> #define ARM64_HAS_STAGE2_FWB 32 > >> +#define ARM64_HAS_CRC32 33 > >> > >> -#define ARM64_NCAPS 33 > >> +#define ARM64_NCAPS 34 > > > > > > ... if this goes via crypto, you'll almost certainly get a (trivial) > > conflict with arm64, since these numbers get bumped all the time. > > > > I think the first three patches should go through the arm64 tree. The > last one just removes the now redundant crc32 SIMD driver, and Herbert > could pick that up separately, i.e., it should be totally independent. Yes let's do that. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: xts - Drop use of auxiliary buffer
Ondrej Mosnacek wrote: > Hi Herbert, Mikulas, > > I noticed the discussion about using kmalloc() inside crypto code and it > made me wonder if the code in xts.c can actually be simplified to not > require kmalloc() at all, while not badly affecting performace. I played > around with it a little and it turns out we can drop the whole caching > of tweak blocks, reducing code size by ~200 lines and not only preserve, > but even improve the performance in some cases. See the full patch > below. > > Obviously, this doesn't solve the general issue of using kmalloc() in > crypto API routines, but it does resolve the original reported problem > and also makes the XTS code easier to maintain. Nice work. Unfortunately it doesn't apply against the latest cryptodev tree. Please rebase and resubmit. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v8 0/9] crypto: Remove VLA usage
On Mon, Sep 3, 2018 at 10:19 PM, Herbert Xu wrote: > On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote: >> v8 cover letter: >> >> I continue to hope this can land in v4.19, but I realize that's unlikely. >> It would be nice, though, if some of the "trivial" patches could get taken >> (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them. >> *fingers crossed* >> >> Series cover letter: >> >> This is nearly the last of the VLA removals[1], but it's one of the >> largest because crypto gets used in lots of places. After looking >> through code, usage, reading the threads Gustavo started, and comparing >> the use-cases to the other VLA removals that have landed in the kernel, >> I think this series is likely the best way forward to shut the door on >> VLAs forever. >> >> For background, the crypto stack usage is for callers to do an immediate >> bit of work that doesn't allocate new memory. This means that other VLA >> removal techniques (like just using kmalloc) aren't workable, and the >> next common technique is needed: examination of maximum stack usage and >> the addition of sanity checks. This series does that, and in several >> cases, these maximums were already implicit in the code. >> >> This series is intended to land via the crypto tree for 4.19, though it >> touches dm, networking, and a few other things as well, since there are >> dependent patches (new crypto #defines being used, etc). > > I have applied patches 1-4 and 6-8. I'd like to get an ack from > the dm folks regarding patch 5. As to patch 9, please fix it so > it doesn't rely on the BUG_ON to catch things. Great! Thanks very much. I'll get a patch prepared to plumb crypto_skcipher_set_reqsize() failures. -Kees -- Kees Cook Pixel Security
