Re: [PATCH v8 6/6] docs: trusted-encrypted: add DCP as new trust source
On Wed, Apr 03, 2024 at 06:47:51PM +0300, Jarkko Sakkinen wrote: > > Reviewed-by: Jarkko Sakkinen > > I can only test that this does not break a machine without the > hardware feature. Please feel free to take this through your tree. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] powerpc/crypto/chacha-p10: Fix failure on non Power10
On Fri, Mar 29, 2024 at 12:02:00AM +1100, Michael Ellerman wrote: > The chacha-p10-crypto module provides optimised chacha routines for > Power10. It also selects CRYPTO_ARCH_HAVE_LIB_CHACHA which says it > provides chacha_crypt_arch() to generic code. > > Notably the module needs to provide chacha_crypt_arch() regardless of > whether it is loaded on Power10 or an older CPU. > > The implementation of chacha_crypt_arch() already has a fallback to > chacha_crypt_generic(), however the module as a whole fails to load on > pre-Power10, because of the use of module_cpu_feature_match(). > > This breaks for example loading wireguard: > > jostaberry-1:~ # modprobe -v wireguard > insmod > /lib/modules/6.8.0-lp155.8.g7e0e887-default/kernel/arch/powerpc/crypto/chacha-p10-crypto.ko.zst > modprobe: ERROR: could not insert 'wireguard': No such device > > Fix it by removing module_cpu_feature_match(), and instead check the > CPU feature manually. If the CPU feature is not found, the module > still loads successfully, but doesn't register the Power10 specific > algorithms. That allows chacha_crypt_generic() to remain available for > use, fixing the problem. > > [root@fedora ~]# modprobe -v wireguard > insmod /lib/modules/6.8.0-1-g786a790c4d79/kernel/net/ipv4/udp_tunnel.ko > insmod > /lib/modules/6.8.0-1-g786a790c4d79/kernel/net/ipv6/ip6_udp_tunnel.ko > insmod /lib/modules/6.8.0-1-g786a790c4d79/kernel/lib/crypto/libchacha.ko > insmod > /lib/modules/6.8.0-1-g786a790c4d79/kernel/arch/powerpc/crypto/chacha-p10-crypto.ko > insmod > /lib/modules/6.8.0-1-g786a790c4d79/kernel/lib/crypto/libchacha20poly1305.ko > insmod > /lib/modules/6.8.0-1-g786a790c4d79/kernel/drivers/net/wireguard/wireguard.ko > [ 18.910452][ T721] wireguard: allowedips self-tests: pass > [ 18.914999][ T721] wireguard: nonce counter self-tests: pass > [ 19.029066][ T721] wireguard: ratelimiter self-tests: pass > [ 19.029257][ T721] wireguard: WireGuard 1.0.0 loaded. See > www.wireguard.com for information. > [ 19.029361][ T721] wireguard: Copyright (C) 2015-2019 Jason A. > Donenfeld . All Rights Reserved. > > Reported-by: Michal Suchánek > Closes: https://lore.kernel.org/all/20240315122005.gg20...@kitsune.suse.cz/ > Signed-off-by: Michael Ellerman > --- > arch/powerpc/crypto/chacha-p10-glue.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) Acked-by: Herbert Xu Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH][next] crypto/nx: Avoid -Wflex-array-member-not-at-end warning
On Tue, Mar 05, 2024 at 01:57:56PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally. So, we are deprecating flexible-array
> members in the middle of another structure.
>
> There is currently an object (`header`) in `struct nx842_crypto_ctx`
> that contains a flexible structure (`struct nx842_crypto_header`):
>
> struct nx842_crypto_ctx {
> ...
> struct nx842_crypto_header header;
> struct nx842_crypto_header_group group[NX842_CRYPTO_GROUP_MAX];
> ...
> };
>
> So, in order to avoid ending up with a flexible-array member in the
> middle of another struct, we use the `struct_group_tagged()` helper to
> separate the flexible array from the rest of the members in the flexible
> structure:
>
> struct nx842_crypto_header {
> struct_group_tagged(nx842_crypto_header_hdr, hdr,
>
> ... the rest of the members
>
> );
> struct nx842_crypto_header_group group[];
> } __packed;
>
> With the change described above, we can now declare an object of the
> type of the tagged struct, without embedding the flexible array in the
> middle of another struct:
>
> struct nx842_crypto_ctx {
> ...
> struct nx842_crypto_header_hdr header;
> struct nx842_crypto_header_group group[NX842_CRYPTO_GROUP_MAX];
> ...
> } __packed;
>
> We also use `container_of()` whenever we need to retrieve a pointer to
> the flexible structure, through which we can access the flexible
> array if needed.
>
> So, with these changes, fix the following warning:
>
> In file included from drivers/crypto/nx/nx-842.c:55:
> drivers/crypto/nx/nx-842.h:174:36: warning: structure containing a flexible
> array member is not at the end of another structure
> [-Wflex-array-member-not-at-end]
> 174 | struct nx842_crypto_header header;
> |^~
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/crypto/nx/nx-842.c | 6 --
> drivers/crypto/nx/nx-842.h | 10 ++
> 2 files changed, 10 insertions(+), 6 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: Cannot load wireguard module
On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote: > > This diff fixes it for me: Yes I think this is the correct fix. 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] MAINTAINERS: adjust file entries after crypto vmx file movement
On Thu, Feb 08, 2024 at 10:33:27AM +0100, Lukas Bulwahn wrote:
> Commit 109303336a0c ("crypto: vmx - Move to arch/powerpc/crypto") moves the
> crypto vmx files to arch/powerpc, but misses to adjust the file entries for
> IBM Power VMX Cryptographic instructions and LINUX FOR POWERPC.
>
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about
> broken references.
>
> Adjust these file entries accordingly. To keep the matched files exact
> after the movement, spell out each file name in the new directory.
>
> Signed-off-by: Lukas Bulwahn
> ---
> v1:
> https://lore.kernel.org/lkml/20240129131729.4311-1-lukas.bulw...@gmail.com/
>
> v1 -> v2:
> - address Herbert Xu's feedback:
> keep the matched files exactly those which were in the vmx directory
>
> Danny, please ack.
> Herbert, please pick this minor clean-up patch on your -next tree.
>
> MAINTAINERS | 18 +++---
> 1 file changed, 11 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] MAINTAINERS: adjust file entries after crypto vmx file movement
On Mon, Jan 29, 2024 at 02:17:29PM +0100, Lukas Bulwahn wrote: > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2fb944964be5..15bc79e80e28 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10307,12 +10307,12 @@ M: Nayna Jain > M: Paulo Flabiano Smorigo > L: linux-cry...@vger.kernel.org > S: Supported > -F: drivers/crypto/vmx/Kconfig > -F: drivers/crypto/vmx/Makefile > -F: drivers/crypto/vmx/aes* > -F: drivers/crypto/vmx/ghash* > -F: drivers/crypto/vmx/ppc-xlate.pl > -F: drivers/crypto/vmx/vmx.c > +F: arch/powerpc/crypto/Kconfig > +F: arch/powerpc/crypto/Makefile > +F: arch/powerpc/crypto/aes* Are you sure about this? There are non-vmx aes* files in that directory. Perhaps something more specific is needed here? 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:vmx: Move ppc vmx diirectory to arch/powerpc/crypto.
On Tue, Jan 02, 2024 at 03:58:56PM -0500, Danny Tsen wrote:
> Relocate all crypto files in vmx driver to arch/powerpc/crypto directory
> and remove vmx directory.
>
> drivers/crypto/vmx/aes.c rename to arch/powerpc/crypto/aes.c
> drivers/crypto/vmx/aes_cbc.c rename to arch/powerpc/crypto/aes_cbc.c
> drivers/crypto/vmx/aes_ctr.c rename to arch/powerpc/crypto/aes_ctr.c
> drivers/crypto/vmx/aes_xts.c rename to arch/powerpc/crypto/aes_xts.c
> drivers/crypto/vmx/aesp8-ppc.h rename to arch/powerpc/crypto/aesp8-ppc.h
> drivers/crypto/vmx/aesp8-ppc.pl rename to arch/powerpc/crypto/aesp8-ppc.pl
> drivers/crypto/vmx/ghash.c rename to arch/powerpc/crypto/ghash.c
> drivers/crypto/vmx/ghashp8-ppc.pl rename to arch/powerpc/crypto/ghashp8-ppc.pl
> drivers/crypto/vmx/vmx.c rename to arch/powerpc/crypto/vmx.c
>
> deleted files:
> drivers/crypto/vmx/Makefile
> drivers/crypto/vmx/Kconfig
> drivers/crypto/vmx/ppc-xlate.pl
>
> This patch has been tested has passed the selftest. The patch is also tested
> with
> CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.
>
> Signed-off-by: Danny Tsen
> ---
> arch/powerpc/crypto/Kconfig | 20 ++
> arch/powerpc/crypto/Makefile | 20 +-
> .../crypto/vmx => arch/powerpc/crypto}/aes.c | 0
> .../vmx => arch/powerpc/crypto}/aes_cbc.c | 0
> .../vmx => arch/powerpc/crypto}/aes_ctr.c | 0
> .../vmx => arch/powerpc/crypto}/aes_xts.c | 0
> .../vmx => arch/powerpc/crypto}/aesp8-ppc.h | 0
> .../vmx => arch/powerpc/crypto}/aesp8-ppc.pl | 0
> .../vmx => arch/powerpc/crypto}/ghash.c | 0
> .../powerpc/crypto}/ghashp8-ppc.pl| 0
> .../crypto/vmx => arch/powerpc/crypto}/vmx.c | 0
> drivers/crypto/Kconfig| 14 +-
> drivers/crypto/Makefile | 2 +-
> drivers/crypto/vmx/.gitignore | 3 -
> drivers/crypto/vmx/Kconfig| 14 --
> drivers/crypto/vmx/Makefile | 23 --
> drivers/crypto/vmx/ppc-xlate.pl | 231 --
> 17 files changed, 46 insertions(+), 281 deletions(-)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes.c (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_cbc.c (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_ctr.c (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_xts.c (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aesp8-ppc.h (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/aesp8-ppc.pl (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/ghash.c (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/ghashp8-ppc.pl (100%)
> rename {drivers/crypto/vmx => arch/powerpc/crypto}/vmx.c (100%)
> delete mode 100644 drivers/crypto/vmx/.gitignore
> delete mode 100644 drivers/crypto/vmx/Kconfig
> delete mode 100644 drivers/crypto/vmx/Makefile
> delete mode 100644 drivers/crypto/vmx/ppc-xlate.pl
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][next] powerpc/crypto: Avoid -Wstringop-overflow warnings
On Tue, Nov 21, 2023 at 12:52:44PM -0600, Gustavo A. R. Silva wrote:
> The compiler doesn't know that `32` is an offset into the Hash table:
>
> 56 struct Hash_ctx {
> 57 u8 H[16]; /* subkey */
> 58 u8 Htable[256]; /* Xi, Hash table(offset 32) */
> 59 };
>
> So, it legitimately complains about a potential out-of-bounds issue
> if `256 bytes` are accessed in `htable` (this implies going
> `32 bytes` beyond the boundaries of `Htable`):
>
> arch/powerpc/crypto/aes-gcm-p10-glue.c: In function 'gcmp10_init':
> arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: error: 'gcm_init_htable'
> accessing 256 bytes in a region of size 224 [-Werror=stringop-overflow=]
> 120 | gcm_init_htable(hash->Htable+32, hash->H);
> | ^
> arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 1 of
> type 'unsigned char[256]'
> arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 2 of
> type 'unsigned char[16]'
> arch/powerpc/crypto/aes-gcm-p10-glue.c:40:17: note: in a call to function
> 'gcm_init_htable'
>40 | asmlinkage void gcm_init_htable(unsigned char htable[256], unsigned
> char Xi[16]);
> | ^~~
>
> Address this by avoiding specifying the size of `htable` in the function
> prototype; and just for consistency, do the same for parameter `Xi`.
>
> Reported-by: Stephen Rothwell
> Closes:
> https://lore.kernel.org/linux-next/20231121131903.68a37...@canb.auug.org.au/
> Signed-off-by: Gustavo A. R. Silva
> ---
> arch/powerpc/crypto/aes-gcm-p10-glue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
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 v4 1/5] crypto: mxs-dcp: Add support for hardware-bound keys
On Tue, Oct 24, 2023 at 06:20:15PM +0200, David Gstir wrote: > DCP is capable of performing AES with two hardware-bound keys: > > - The one-time programmable (OTP) key which is burnt via on-chip fuses > - The unique key (UK) which is derived from the OTP key > > In addition to the two hardware-bound keys, DCP also supports > storing keys in 4 dedicated key slots within its secure memory area > (internal SRAM). > > These keys are not stored in main memory and are therefore > not directly accessible by the operating system. To use them > for AES operations, a one-byte key reference has to supplied > with the DCP operation descriptor in the control register. > > This adds support for using any of these 6 keys through the crypto API > via their key reference after they have been set up. The main purpose > is to add support for DCP-backed trusted keys. Other use cases are > possible too (see similar existing paes implementations), but these > should carefully be evaluated as e.g. enabling AF_ALG will give > userspace full access to use keys. In scenarios with untrustworthy > userspace, this will enable en-/decryption oracles. > > Co-developed-by: Richard Weinberger > Signed-off-by: Richard Weinberger > Co-developed-by: David Oberhollenzer > Signed-off-by: David Oberhollenzer > Signed-off-by: David Gstir > --- > drivers/crypto/mxs-dcp.c | 104 ++- > include/soc/fsl/dcp.h| 17 +++ > 2 files changed, 110 insertions(+), 11 deletions(-) > create mode 100644 include/soc/fsl/dcp.h Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: vmx: Improved AES/XTS performance of 6-way unrolling for ppc.
On Wed, Aug 30, 2023 at 09:49:11AM -0400, Danny Tsen wrote: > Improve AES/XTS performance of 6-way unrolling for PowerPC up > to 17% with tcrypt. This is done by using one instruction, > vpermxor, to replace xor and vsldoi. > > The same changes were applied to OpenSSL code and a pull request was > submitted. > > This patch has been tested with the kernel crypto module tcrypt.ko and > has passed the selftest. The patch is also tested with > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled. > > Signed-off-by: Danny Tsen > --- > drivers/crypto/vmx/aesp8-ppc.pl | 141 +--- > 1 file changed, 92 insertions(+), 49 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
crypto: powerpc/chacha20,poly1305-p10 - Add dependency on VSX
On Fri, Aug 25, 2023 at 07:44:32PM +0800, kernel test robot wrote:
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/powerpc/crypto/poly1305-p10-glue.c:19:
...
> ae3a197e3d0bfe3 David Howells2012-03-28 75
> ae3a197e3d0bfe3 David Howells2012-03-28 76 #ifdef CONFIG_VSX
> d1e1cf2e38def30 Anton Blanchard 2015-10-29 77 extern void
> enable_kernel_vsx(void);
> ae3a197e3d0bfe3 David Howells2012-03-28 78 extern void
> flush_vsx_to_thread(struct task_struct *);
> 3eb5d5888dc68c9 Anton Blanchard 2015-10-29 79 static inline void
> disable_kernel_vsx(void)
> 3eb5d5888dc68c9 Anton Blanchard 2015-10-29 80 {
> 3eb5d5888dc68c9 Anton Blanchard 2015-10-29 81
> msr_check_and_clear(MSR_FP|MSR_VEC|MSR_VSX);
> 3eb5d5888dc68c9 Anton Blanchard 2015-10-29 82 }
> bd73758803c2eed Christophe Leroy 2021-03-09 83 #else
> bd73758803c2eed Christophe Leroy 2021-03-09 84 static inline void
> enable_kernel_vsx(void)
> bd73758803c2eed Christophe Leroy 2021-03-09 85 {
> bd73758803c2eed Christophe Leroy 2021-03-09 @86 BUILD_BUG();
> bd73758803c2eed Christophe Leroy 2021-03-09 87 }
> bd73758803c2eed Christophe Leroy 2021-03-09 88
---8<---
Add dependency on VSX as otherwise the build will fail without
it.
Fixes: 161fca7e3e90 ("crypto: powerpc - Add chacha20/poly1305-p10 to Kconfig
and Makefile")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202308251906.syawej6g-...@intel.com/
Signed-off-by: Herbert Xu
diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index f25024afdda5..7a66d7c0e6a2 100644
--- a/arch/powerpc/crypto/Kconfig
+++ b/arch/powerpc/crypto/Kconfig
@@ -113,7 +113,7 @@ config CRYPTO_AES_GCM_P10
config CRYPTO_CHACHA20_P10
tristate "Ciphers: ChaCha20, XChacha20, XChacha12 (P10 or later)"
- depends on PPC64 && CPU_LITTLE_ENDIAN
+ depends on PPC64 && CPU_LITTLE_ENDIAN && VSX
select CRYPTO_SKCIPHER
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CHACHA
@@ -127,7 +127,7 @@ config CRYPTO_CHACHA20_P10
config CRYPTO_POLY1305_P10
tristate "Hash functions: Poly1305 (P10 or later)"
- depends on PPC64 && CPU_LITTLE_ENDIAN
+ depends on PPC64 && CPU_LITTLE_ENDIAN && VSX
select CRYPTO_HASH
select CRYPTO_LIB_POLY1305_GENERIC
help
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] hwrng: Explicitly include correct DT includes
On Fri, Jul 28, 2023 at 07:48:27AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it was merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > v3: > - Split out hw_random, ipmi and tpm > v2: > - Fix build for pic32-rng.c dropping of_match_ptr() > --- > drivers/char/hw_random/atmel-rng.c | 2 +- > drivers/char/hw_random/bcm2835-rng.c | 3 +-- > drivers/char/hw_random/ingenic-trng.c | 2 +- > drivers/char/hw_random/iproc-rng200.c | 3 +-- > drivers/char/hw_random/npcm-rng.c | 3 +-- > drivers/char/hw_random/omap-rng.c | 2 -- > drivers/char/hw_random/omap3-rom-rng.c | 1 - > drivers/char/hw_random/pasemi-rng.c| 3 +-- > drivers/char/hw_random/pic32-rng.c | 5 ++--- > drivers/char/hw_random/stm32-rng.c | 3 ++- > drivers/char/hw_random/xgene-rng.c | 5 ++--- > drivers/char/hw_random/xiphera-trng.c | 1 - > 12 files changed, 12 insertions(+), 21 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: [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs
On Fri, Jul 28, 2023 at 12:03:23PM +0200, Ard Biesheuvel wrote: > > Fair enough. But my point remains: this requires a lot of boilerplate > on the part of the driver, and it would be better if we could do this > in the acomp generic layer. Absolutely. If the hardware can't support allocate-as-you-go then this should very much go into the generic layer. > Does the IPcomp case always know the decompressed size upfront? No it doesn't know. Of course, we could optimise it because we know that in 99% cases, the packet is going to be less than 4K. But we need a safety-net for those weird jumbo packets. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs
On Fri, Jul 28, 2023 at 11:57:42AM +0200, Ard Biesheuvel wrote: > > So will IPcomp be able to simply assign those pages to the SKB afterwards? Yes that is the idea. The network stack is very much in love with SG lists :) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs
On Tue, Jul 18, 2023 at 02:58:26PM +0200, Ard Biesheuvel wrote: > > Patch #2 removes the support for on-the-fly allocation of destination > buffers and scatterlists from the Intel QAT driver. This is never used, > and not even implemented by all drivers (the HiSilicon ZIP driver does > not support it). The diffstat of this patch makes a good case why the > caller should be in charge of allocating the memory, not the driver. The implementation in qat may not be optimal, but being able to allocate memory in the algorithm is a big plus for IPComp at least. Being able to allocate memory page by page as you decompress means that: 1. We're not affected by memory fragmentation. 2. We don't waste memory by always allocating for the worst case. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/5] crypto: Accelerated Chacha20/Poly1305 implementation
On Wed, Apr 26, 2023 at 03:11:42PM -0400, Danny Tsen wrote: > This patch series provide an accelerated/optimized Chacha20 and Poly1305 > implementation for Power10 or later CPU (ppc64le). This module > implements algorithm specified in RFC7539. The implementation > provides 3.5X better performance than the baseline for Chacha20 and > Poly1305 individually and 1.5X improvement for Chacha20/Poly1305 > operation. > > This patch has been tested with the kernel crypto module tcrypt.ko and > has passed the selftest. The patch is also tested with > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled. > > > Danny Tsen (5): > An optimized Chacha20 implementation with 8-way unrolling for ppc64le. > Glue code for optmized Chacha20 implementation for ppc64le. > An optimized Poly1305 implementation with 4-way unrolling for ppc64le. > Glue code for optmized Poly1305 implementation for ppc64le. > Update Kconfig and Makefile. > > arch/powerpc/crypto/Kconfig | 26 + > arch/powerpc/crypto/Makefile|4 + > arch/powerpc/crypto/chacha-p10-glue.c | 221 + > arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++ > arch/powerpc/crypto/poly1305-p10-glue.c | 186 > arch/powerpc/crypto/poly1305-p10le_64.S | 1075 +++ > 6 files changed, 2354 insertions(+) > create mode 100644 arch/powerpc/crypto/chacha-p10-glue.c > create mode 100644 arch/powerpc/crypto/chacha-p10le-8x.S > create mode 100644 arch/powerpc/crypto/poly1305-p10-glue.c > create mode 100644 arch/powerpc/crypto/poly1305-p10le_64.S > > -- > 2.31.1 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: linux-next: build failure after merge of the crypto tree
On Mon, Jun 26, 2023 at 12:39:46PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the crypto tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ld: warning: discarding dynamic section .glink
> ld: warning: discarding dynamic section .plt
> ld: linkage table error against `sm2_compute_z_digest'
> ld: stubs don't match calculated size
> ld: can not build stubs: bad value
> ld: crypto/asymmetric_keys/x509_public_key.o: in function
> `x509_get_sig_params':
> x509_public_key.c:(.text+0x474): undefined reference to `sm2_compute_z_digest'
>
> Possibly caused by commit
>
> e5221fa6a355 ("KEYS: asymmetric: Move sm2 code into x509_public_key")
>
> This looks like it may be a compiler bug? Maybe the deep ternary
> expressions may be contributing to that? (cc'ing the ppc guys in case
> they have any ideas.)
>
> I have reverted that commit (and the following one) for today.
Thanks Stephen. I've just pushed out a fix for this.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] powerpc/crypto: fix build warnings when DEBUG_FS is not enabled
On Fri, May 19, 2023 at 03:33:34PM -0700, Randy Dunlap wrote:
> Fix build warnings when DEBUG_FS is not enabled by using an empty
> do-while loop instead of a value:
>
> In file included from ../drivers/crypto/nx/nx.c:27:
> ../drivers/crypto/nx/nx.c: In function 'nx_register_algs':
> ../drivers/crypto/nx/nx.h:173:33: warning: statement with no effect
> [-Wunused-value]
> 173 | #define NX_DEBUGFS_INIT(drv)(0)
> ../drivers/crypto/nx/nx.c:573:9: note: in expansion of macro 'NX_DEBUGFS_INIT'
> 573 | NX_DEBUGFS_INIT(_driver);
> ../drivers/crypto/nx/nx.c: In function 'nx_remove':
> ../drivers/crypto/nx/nx.h:174:33: warning: statement with no effect
> [-Wunused-value]
> 174 | #define NX_DEBUGFS_FINI(drv)(0)
> ../drivers/crypto/nx/nx.c:793:17: note: in expansion of macro
> 'NX_DEBUGFS_FINI'
> 793 | NX_DEBUGFS_FINI(_driver);
>
> Also, there is no need to build nx_debugfs.o when DEBUG_FS is not
> enabled, so change the Makefile to accommodate that.
>
> Fixes: ae0222b7289d ("powerpc/crypto: nx driver code supporting nx
> encryption")
> Fixes: aef7b31c8833 ("powerpc/crypto: Build files for the nx device driver")
> Signed-off-by: Randy Dunlap
> Cc: Breno Leitão
> Cc: Nayna Jain
> Cc: Paulo Flabiano Smorigo
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-cry...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> drivers/crypto/nx/Makefile |2 +-
> drivers/crypto/nx/nx.h |4 ++--
> 2 files changed, 3 insertions(+), 3 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 5/5] Update Kconfig and Makefile.
On Mon, Apr 24, 2023 at 02:47:26PM -0400, Danny Tsen wrote: > > +config CRYPTO_CHACHA20_P10 > + tristate "Ciphers: ChaCha20, XChacha20, XChacha12 (P10 or later)" > + depends on PPC64 && CPU_LITTLE_ENDIAN > + select CRYPTO_SKCIPHER I thought your IS_REACHABLE test was so that you could build this without the Crypto API? Colour me confused. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 4/5] Glue code for optmized Poly1305 implementation for ppc64le.
On Mon, Apr 24, 2023 at 02:47:25PM -0400, Danny Tsen wrote:
>
> + if (likely(srclen >= POLY1305_BLOCK_SIZE)) {
> + bytes = round_down(srclen, POLY1305_BLOCK_SIZE);
> + used = crypto_poly1305_setdctxkey(dctx, src, bytes);
> + if (likely(used)) {
> + srclen -= used;
> + src += used;
> + }
> + if (srclen >= POLY1305_BLOCK_SIZE*4) {
> + vsx_begin();
Your chacha code has a SIMD-fallback, how come this one doesn't?
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/5] Glue code for optmized Chacha20 implementation for ppc64le.
On Mon, Apr 24, 2023 at 02:47:23PM -0400, Danny Tsen wrote:
>
> +static int chacha_p10_stream_xor(struct skcipher_request *req,
> + const struct chacha_ctx *ctx, const u8 *iv)
> +{
> + struct skcipher_walk walk;
> + u32 state[16];
> + int err;
> +
> + err = skcipher_walk_virt(, req, false);
> + if (err)
> + return err;
> +
> + chacha_init_generic(state, ctx->key, iv);
> +
> + while (walk.nbytes > 0) {
> + unsigned int nbytes = walk.nbytes;
> +
> + if (nbytes < walk.total)
> + nbytes = rounddown(nbytes, walk.stride);
> +
> + if (!static_branch_likely(_p10) ||
You don't need the static branch in the Crypto API code since
the registration is already conditional.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/5] Glue code for optmized Chacha20 implementation for ppc64le.
On Tue, Apr 25, 2023 at 01:37:22PM +0800, Herbert Xu wrote:
> On Mon, Apr 24, 2023 at 02:47:23PM -0400, Danny Tsen wrote:
> >
> > +static int __init chacha_p10_init(void)
> > +{
> > + static_branch_enable(_p10);
> > +
> > + return IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER) ?
> > + crypto_register_skciphers(algs, ARRAY_SIZE(algs)) : 0;
>
> What is this for? The usual way is to select CRYPTO_SKCIPHER
> rather than have a mysterious failure at run-time.
Nevermind, I see that you also have non-Crypto API code in there.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/5] Glue code for optmized Chacha20 implementation for ppc64le.
On Mon, Apr 24, 2023 at 02:47:23PM -0400, Danny Tsen wrote:
>
> +static int __init chacha_p10_init(void)
> +{
> + static_branch_enable(_p10);
> +
> + return IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER) ?
> + crypto_register_skciphers(algs, ARRAY_SIZE(algs)) : 0;
What is this for? The usual way is to select CRYPTO_SKCIPHER
rather than have a mysterious failure at run-time.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
On Thu, Apr 13, 2023 at 03:46:23PM -0400, Danny Tsen wrote: > Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. > Move PPC_MODULE_FEATURE_P10 definition to be in > arch/powerpc/include/asm/cpufeature.h. > > Signed-off-by: Danny Tsen > > Danny Tsen (2): > Kconfig: Remove POWER10_CPU dependency. > aes-gcm-p10-glue.c, cpufeature.h: Move Power10 feature, > PPC_MODULE_FEATURE_P10. > > arch/powerpc/crypto/Kconfig| 2 +- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > arch/powerpc/include/asm/cpufeature.h | 1 + > 3 files changed, 2 insertions(+), 2 deletions(-) > > -- > 2.31.1 All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: p10-aes-gcm - remove duplicate include header
On Tue, Mar 14, 2023 at 04:31:51PM +0800, ye.xingc...@zte.com.cn wrote: > From: Ye Xingchen > > crypto/algapi.h is included more than once. > > Signed-off-by: Ye Xingchen > --- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > 1 file changed, 1 deletion(-) 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: p10-aes-gcm - remove duplicate include header
On Thu, Mar 16, 2023 at 02:58:04PM +1100, Michael Ellerman wrote: > > Although one question I do have for you is what rules, if any, do we > have for deciding whether crypto code goes in drivers/crypto vs > arch/*/crypto? If it's on the CPU then it should probably live under arch. Yes there have been exceptions in the past, with VIA PadLock on x86 and vmx on PPC being prime examples. > I wonder if we should move drivers/crypto/vmx into arch/powerpc/crypto, > so that all the powerpc CRYPTOGAMS code is in one place. That would help > to clean up some of the duplication of perl scripts we now have. Yes I think that would certainly make sense. 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: p10-aes-gcm - remove duplicate include header
On Tue, Mar 14, 2023 at 09:44:52PM +1100, Michael Ellerman wrote: > > Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the > first I've seen of them. Sorry, I didn't know that you weren't aware of this change. I will be more careful with these ppc patches in future. 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: p10-aes-gcm - remove duplicate include header
On Tue, Mar 14, 2023 at 08:47:30AM +, Christophe Leroy wrote: > > Any reason for resending ? The p10 patches were reverted, and have only just been re-instated. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: crypto: p10-aes-gcm - Add asm markings necessary for kernel code
On Wed, Jan 18, 2023 at 02:04:44PM +1100, Stephen Rothwell wrote: > > arch/powerpc/crypto/aesp8-ppc.o: warning: objtool: > aes_p8_set_encrypt_key+0x44: unannotated intra-function call > > from the powerpc pseries_le_defconfig build (which is otherwise ok). Thanks Stephen. I've reverted these changes completely. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
crypto: p10-aes-gcm - Add asm markings necessary for kernel code
On Tue, Jan 17, 2023 at 02:47:47PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the crypto tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
>
> arch/powerpc/crypto/p10_aes_gcm.o: warning: objtool: .text+0x884: unannotated
> intra-function call
> arch/powerpc/crypto/aesp8-ppc.o: warning: objtool:
> aes_p8_set_encrypt_key+0x44: unannotated intra-function call
> ld: arch/powerpc/crypto/p10_aes_gcm.o: ABI version 1 is not compatible with
> ABI version 2 output
> ld: failed to merge target specific data of file
> arch/powerpc/crypto/p10_aes_gcm.o
>
> Caused by commit
>
> ca68a96c37eb ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched
> implementation")
>
> I have applied the following hack for today.
Thanks Stephen, I'm going to update the previous fix as follows:
---8<---
_GLOBAL is needed instead of .global on Linux in assembly code.
The explicit abiversion setting is removed as the code should
with either ABI.
Mark local functions to avoid objdump warnings.
Reported-by: Stephen Rothwell
Fixes: cc40379b6e19 ("crypto: p10-aes-gcm - Glue code for AES/GCM stitched
implementation")
Fixes: 3b47eccaaff4 ("crypto: p10-aes-gcm - Supporting functions for AES")
Signed-off-by: Herbert Xu
diff --git a/arch/powerpc/crypto/aesp8-ppc.pl b/arch/powerpc/crypto/aesp8-ppc.pl
index 50a0a18f35da..cdbcf6e13efc 100644
--- a/arch/powerpc/crypto/aesp8-ppc.pl
+++ b/arch/powerpc/crypto/aesp8-ppc.pl
@@ -121,6 +121,22 @@ my ($inp,$bits,$out,$ptr,$cnt,$rounds)=map("r$_",(3..8));
my ($zero,$in0,$in1,$key,$rcon,$mask,$tmp)=map("v$_",(0..6));
my ($stage,$outperm,$outmask,$outhead,$outtail)=map("v$_",(7..11));
+sub declare_function() {
+ my ($name) = @_;
+ if ($kernel) {
+ $code .= "SYM_FUNC_START_LOCAL($name)\n";
+ } else {
+ $code .= "L$name:\n";
+ }
+}
+
+sub end_function() {
+ my ($name) = @_;
+ if ($kernel) {
+ $code .= "SYM_FUNC_END($name)\n";
+ }
+}
+
$code.=<<___;
.machine "any"
@@ -132,13 +148,18 @@ rcon:
.long 0x1b00, 0x1b00, 0x1b00, 0x1b00 ?rev
.long 0x0d0e0f0c, 0x0d0e0f0c, 0x0d0e0f0c, 0x0d0e0f0c ?rev
.long 0,0,0,0 ?asis
-Lconsts:
+___
+_function("consts");
+$code.=<<___;
mflrr0
bcl 20,31,\$+4
mflr$ptr #v "distance between . and rcon
addi$ptr,$ptr,-0x48
mtlrr0
blr
+___
+_function("consts");
+$code.=<<___;
.long 0
.byte 0,12,0x14,0,0,0,0,0
.asciz "AES for PowerISA 2.07, CRYPTOGAMS by "
diff --git a/arch/powerpc/crypto/p10_aes_gcm.S
b/arch/powerpc/crypto/p10_aes_gcm.S
index 2306ad7c5e36..153388733eae 100644
--- a/arch/powerpc/crypto/p10_aes_gcm.S
+++ b/arch/powerpc/crypto/p10_aes_gcm.S
@@ -38,8 +38,10 @@
#
===
#
+#include
+#include
+
.machine"any"
-.abiversion 1
.text
# 4x loops
@@ -569,9 +571,7 @@ ppc_aes_gcm_ghash:
#rounds is at offset 240 in rk
#Xi is at 0 in gcm_table (Xip).
#
-.global aes_p10_gcm_encrypt
-.align 5
-aes_p10_gcm_encrypt:
+_GLOBAL(aes_p10_gcm_encrypt)
SAVE_REGS
@@ -989,7 +989,7 @@ Normal_block:
# Handle multiple partial blocks for encrypt and decrypt
# operations.
#
-Do_partial_block:
+SYM_FUNC_START_LOCAL(Do_partial_block)
add 17, 15, 5
cmpdi 17, 16
bgt Big_block
@@ -1075,6 +1075,7 @@ Save_partial:
Partial_done:
blr
+SYM_FUNC_END(Do_partial_block)
#
# Write partial block
@@ -1082,7 +1083,7 @@ Partial_done:
# r12 - remaining bytes
# v15 - partial input data
#
-Write_partial_block:
+SYM_FUNC_START_LOCAL(Write_partial_block)
li 10, 192
stxvb16x15+32, 10, 1# last block
@@ -1097,6 +1098,7 @@ Write_last_byte:
stbu14, 1(10)
bdnz Write_last_byte
blr
+SYM_FUNC_END(Write_partial_block)
aes_gcm_out:
# out = state
@@ -1109,9 +,7 @@ aes_gcm_out:
#
# 8x Decrypt
#
-.global aes_p10_gcm_decrypt
-.align 5
-aes_p10_gcm_decrypt:
+_GLOBAL(aes_p10_gcm_decrypt)
SAVE_REGS
diff --git a/arch/powerpc/crypto/ppc-xlate.pl b/arch/powerpc/crypto/ppc-xlate.pl
index 23cca703ce29..d1dcb914858c 100644
--- a/arch/powerpc/crypto/ppc-xlate.pl
+++ b/arch/powerpc/crypto/ppc-xlate.pl
@@ -198,6 +198,7 @@ my $mtsle = sub {
};
print "#include \n" if $flavour =~ /linux/;
+print "#include \n" if $flavour =~ /linux/;
while($line=<>) {
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: api - Use linux/cache.h instead of asm/cache.h
On Mon, Dec 05, 2022 at 10:52:25AM +1100, Stephen Rothwell wrote:
>
> Or maybe you should have included linux/cache.h instead of asm/cache.h?
You're right Stephen. Thanks!
---8<---
Directly including asm/cache.h leads to build failures on powerpc
so replace it with linux/cache.h instead.
Fixes: e634ac4a8aaa ("crypto: api - Add crypto_tfm_ctx_dma")
Reported-by: Stephen Rothwell
Signed-off-by: Herbert Xu
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 8722fd67f40a..61b327206b55 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -7,8 +7,8 @@
#ifndef _CRYPTO_ALGAPI_H
#define _CRYPTO_ALGAPI_H
-#include
#include
+#include
#include
#include
#include
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH linux-next] crypto: nx - Remove the unneeded result variable
On Fri, Sep 02, 2022 at 07:30:55AM +, cgel@gmail.com wrote: > From: ye xingchen > > Return the value set_msg_len() directly instead of storing it in another > redundant variable. > > Reported-by: Zeal Robot > Signed-off-by: ye xingchen > --- > drivers/crypto/nx/nx-aes-ccm.c | 5 + > 1 file changed, 1 insertion(+), 4 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] cyrpto:delete the rebundant word "block" in comments
shaom Deng wrote: > there is rebundant word "block" in comments, so remove it > > Signed-off-by: shaom Deng > --- > arch/powerpc/crypto/aes-spe-glue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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: nx - drop unexpected word "the"
Jiang Jian wrote: > there is an unexpected word "the" in the comments that need to be dropped > >>- * The DDE is setup with the the DDE count, byte count, and address of >>+ * The DDE is setup with the DDE count, byte count, and address of > > Signed-off-by: Jiang Jian > --- > drivers/crypto/nx/nx-common-powernv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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: vmx - drop unexpected word 'for' in comments
Jiang Jian wrote: > there is an unexpected word 'for' in the comments that need to be dropped > > file - drivers/crypto/vmx/ghashp8-ppc.pl > line - 19 > > "# GHASH for for PowerISA v2.07." > > changed to: > > "# GHASH for PowerISA v2.07." > > Signed-off-by: Jiang Jian > --- > drivers/crypto/vmx/ghashp8-ppc.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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: vmx - Fix build error
On Sat, May 07, 2022 at 02:22:43PM +0900, Masahiro Yamada wrote:
> When I refactored this Makefile, I accidentally changed the CONFIG
> option.
>
> Fixes: b52455a73db9 ("crypto: vmx - Align the short log with Makefile
> cleanups")
> Reported-by: kernel test robot
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/crypto/vmx/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
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: vmx - Align the short log with Makefile cleanups
On Sat, May 07, 2022 at 12:25:32AM +0900, Masahiro Yamada wrote: > > Sorry, I just noticed the 0day bot had reported the error. > > I sent v2.(CONFIG_LITTLE_ENDIAN --> CONFIG_CPU_LITTLE_ENDIAN) > > https://lore.kernel.org/lkml/20220506150820.1310802-1-masahi...@kernel.org/ > > > Could you replace it, or fix it up, please? Please send me an incremental 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] crypto: vmx - Align the short log with Makefile cleanups
On Sun, May 01, 2022 at 10:07:49PM +0900, Masahiro Yamada wrote:
> I notieced the log is not properly aligned:
>
> PERL drivers/crypto/vmx/aesp8-ppc.S
> CC [M] fs/xfs/xfs_reflink.o
> PERL drivers/crypto/vmx/ghashp8-ppc.S
> CC [M] drivers/crypto/vmx/aes.o
>
> Add some spaces after 'PERL'.
>
> While I was here, I cleaned up the Makefile:
>
> - Merge the two similar rules
>
> - Remove redundant 'clean-files' (Having 'targets' is enough)
>
> - Move the flavour into the build command
>
> This still avoids the build failures fixed by commit 4ee812f6143d
> ("crypto: vmx - Avoid weird build failures").
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/crypto/vmx/Makefile | 17 +++--
> 1 file changed, 3 insertions(+), 14 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 v4 1/1] crypto: vmx - add missing dependencies
On Wed, Feb 23, 2022 at 04:11:15PM +0100, Petr Vorel wrote:
> vmx-crypto module depends on CRYPTO_AES, CRYPTO_CBC, CRYPTO_CTR or
> CRYPTO_XTS, thus add them.
>
> These dependencies are likely to be enabled, but if
> CRYPTO_DEV_VMX=y && !CRYPTO_MANAGER_DISABLE_TESTS
> and either of CRYPTO_AES, CRYPTO_CBC, CRYPTO_CTR or CRYPTO_XTS is built
> as module or disabled, alg_test() from crypto/testmgr.c complains during
> boot about failing to allocate the generic fallback implementations
> (2 == ENOENT):
>
> [0.540953] Failed to allocate xts(aes) fallback: -2
> [0.541014] alg: skcipher: failed to allocate transform for p8_aes_xts: -2
> [0.541120] alg: self-tests for p8_aes_xts (xts(aes)) failed (rc=-2)
> [0.50] Failed to allocate ctr(aes) fallback: -2
> [0.544497] alg: skcipher: failed to allocate transform for p8_aes_ctr: -2
> [0.544603] alg: self-tests for p8_aes_ctr (ctr(aes)) failed (rc=-2)
> [0.547992] Failed to allocate cbc(aes) fallback: -2
> [0.548052] alg: skcipher: failed to allocate transform for p8_aes_cbc: -2
> [0.548156] alg: self-tests for p8_aes_cbc (cbc(aes)) failed (rc=-2)
> [0.550745] Failed to allocate transformation for 'aes': -2
> [0.550801] alg: cipher: Failed to load transform for p8_aes: -2
> [0.550892] alg: self-tests for p8_aes (aes) failed (rc=-2)
>
> Fixes: c07f5d3da643 ("crypto: vmx - Adding support for XTS")
> Fixes: d2e3ae6f3aba ("crypto: vmx - Enabling VMX module for PPC64")
>
> Suggested-by: Nicolai Stange
> Signed-off-by: Petr Vorel
> ---
> Changes v3->v4:
> * Drop commit which merged CRYPTO_DEV_VMX and CRYPTO_DEV_VMX_ENCRYPT
> (Herbert)
>
> drivers/crypto/vmx/Kconfig | 4
> 1 file changed, 4 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 2/2] crypto: vmx - add missing dependencies
On Thu, Feb 17, 2022 at 11:57:51AM +0100, Petr Vorel wrote:
> vmx-crypto module depends on CRYPTO_AES, CRYPTO_CBC, CRYPTO_CTR or
> CRYPTO_XTS, thus add them.
>
> These dependencies are likely to be enabled, but if
> CRYPTO_DEV_VMX=y && !CRYPTO_MANAGER_DISABLE_TESTS
> and either of CRYPTO_AES, CRYPTO_CBC, CRYPTO_CTR or CRYPTO_XTS is built
> as module or disabled, alg_test() from crypto/testmgr.c complains during
> boot about failing to allocate the generic fallback implementations
> (2 == ENOENT):
>
> [0.540953] Failed to allocate xts(aes) fallback: -2
> [0.541014] alg: skcipher: failed to allocate transform for p8_aes_xts: -2
> [0.541120] alg: self-tests for p8_aes_xts (xts(aes)) failed (rc=-2)
> [0.50] Failed to allocate ctr(aes) fallback: -2
> [0.544497] alg: skcipher: failed to allocate transform for p8_aes_ctr: -2
> [0.544603] alg: self-tests for p8_aes_ctr (ctr(aes)) failed (rc=-2)
> [0.547992] Failed to allocate cbc(aes) fallback: -2
> [0.548052] alg: skcipher: failed to allocate transform for p8_aes_cbc: -2
> [0.548156] alg: self-tests for p8_aes_cbc (cbc(aes)) failed (rc=-2)
> [0.550745] Failed to allocate transformation for 'aes': -2
> [0.550801] alg: cipher: Failed to load transform for p8_aes: -2
> [0.550892] alg: self-tests for p8_aes (aes) failed (rc=-2)
>
> Fixes: c07f5d3da643 ("crypto: vmx - Adding support for XTS")
> Fixes: d2e3ae6f3aba ("crypto: vmx - Enabling VMX module for PPC64")
>
> Suggested-by: Nicolai Stange
> Signed-off-by: Petr Vorel
> ---
> changes v2->v3:
> * more less the same, just in drivers/crypto/Kconfig (previously it was
> in drivers/crypto/vmx/Kconfig)
> * change commit subject to be compatible
>
> drivers/crypto/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
Please respin this patch to add the selects to the existing tristate.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 1/2] crypto: vmx - merge CRYPTO_DEV_VMX_ENCRYPT into CRYPTO_DEV_VMX
On Thu, Feb 17, 2022 at 11:57:50AM +0100, Petr Vorel wrote: > CRYPTO_DEV_VMX_ENCRYPT is redundant with CRYPTO_DEV_VMX. > > And it also forces CRYPTO_GHASH to be builtin even > CRYPTO_DEV_VMX_ENCRYPT was configured as module. Just because a tristate sits under a bool, it does not force the options that it selects to y/n. The select still operates on the basis of the tristate. So I don't see the point to this code churn unless the powerpc folks want to move in this direction. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] drivers/crypto: Constify static attribute_group
On Thu, Feb 10, 2022 at 09:28:02PM +0100, Rikard Falkeborn wrote: > This series constifies a couple of static attribute_group structs that > are not modified. This allows the compiler to put them in read-only > memory. The patches are independent and can be applied in any order (and > go through different trees if needed). > > Rikard Falkeborn (3): > crypto: omap-aes - Constify static attribute_group > crypto: omap-sham - Constify static attribute_group > crypto/nx: Constify static attribute_group structs > > drivers/crypto/nx/nx-common-pseries.c | 4 ++-- > drivers/crypto/omap-aes.c | 2 +- > drivers/crypto/omap-sham.c| 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] Remove duplicate context init function for sha algorithm
On Mon, Dec 20, 2021 at 05:23:13PM +0800, Tianjia Zhang wrote: > This series of patches is mainly for repetitive code cleaning. The sha > algorithm has provided generic context initialization implementation. > The context initialization code in the optimized implementation of each > platform is a repetitive code and can be deleted. The sha*_base_init() > series of functions are used uniformly. > > Tianjia Zhang (5): > crypto: sha256 - remove duplicate generic hash init function > crypto: mips/sha - remove duplicate hash init function > crypto: powerpc/sha - remove duplicate hash init function > crypto: sparc/sha - remove duplicate hash init function > crypto: s390/sha512 - Use macros instead of direct IV numbers > > arch/mips/cavium-octeon/crypto/octeon-sha1.c | 17 +--- > .../mips/cavium-octeon/crypto/octeon-sha256.c | 39 ++- > .../mips/cavium-octeon/crypto/octeon-sha512.c | 39 ++- > arch/powerpc/crypto/sha1-spe-glue.c | 17 +--- > arch/powerpc/crypto/sha1.c| 14 +-- > arch/powerpc/crypto/sha256-spe-glue.c | 39 ++- > arch/s390/crypto/sha512_s390.c| 32 +++ > arch/sparc/crypto/sha1_glue.c | 14 +-- > arch/sparc/crypto/sha256_glue.c | 37 ++ > arch/sparc/crypto/sha512_glue.c | 37 ++ > crypto/sha256_generic.c | 16 +--- > 11 files changed, 41 insertions(+), 260 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: DRBG - select SHA512
On Mon, Aug 16, 2021 at 04:45:14AM +0200, Christophe Leroy wrote: > > The fixes tag has a problem it seems. Should be corrected before pushing. It's too late for that. This commit is at the base of many other subsequent changes. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: DRBG - select SHA512
On Sat, Aug 14, 2021 at 06:23:26PM +0200, Borislav Petkov wrote: > On Fri, Jul 16, 2021 at 04:14:12PM +0800, Herbert Xu wrote: > > Stephan Mueller wrote: > > > With the swtich to use HMAC(SHA-512) as the default DRBG type, the > > > configuration must now also select SHA-512. > > > > > > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default > > > DRBG" > > > Reported-by: Sachin Sant > > > Signed-off-by: Stephan Mueller > > > --- > > > crypto/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Patch applied. Thanks. > > Is that patch going to Linus anytime soon? > > I still see it on latest rc5+: I'll push it up this week. 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: DRBG - select SHA512
Stephan Mueller wrote: > With the swtich to use HMAC(SHA-512) as the default DRBG type, the > configuration must now also select SHA-512. > > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default > DRBG" > Reported-by: Sachin Sant > Signed-off-by: Stephan Mueller > --- > crypto/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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: nx: Fix memcpy() over-reading in nonce
On Wed, Jun 16, 2021 at 01:34:59PM -0700, Kees Cook wrote:
> Fix typo in memcpy() where size should be CTR_RFC3686_NONCE_SIZE.
>
> Fixes: 030f4e968741 ("crypto: nx - Fix reentrancy bugs")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/crypto/nx/nx-aes-ctr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: scatterwalk - Remove obsolete PageSlab check
On Fri, Jun 18, 2021 at 11:12:58AM -0700, Ira Weiny wrote: > > Interesting! Thanks! > > Digging around a bit more I found: > > https://lore.kernel.org/patchwork/patch/439637/ Nice find. So we can at least get rid of the PageSlab call from the Crypto API. ---8<--- As it is now legal to call flush_dcache_page on slab pages we no longer need to do the check in the Crypto API. Reported-by: Ira Weiny Signed-off-by: Herbert Xu diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h index c837d0775474..7af08174a721 100644 --- a/include/crypto/scatterwalk.h +++ b/include/crypto/scatterwalk.h @@ -81,12 +81,7 @@ static inline void scatterwalk_pagedone(struct scatter_walk *walk, int out, struct page *page; page = sg_page(walk->sg) + ((walk->offset - 1) >> PAGE_SHIFT); - /* Test ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE first as -* PageSlab cannot be optimised away per se due to -* use of volatile pointer. -*/ - if (ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE && !PageSlab(page)) - flush_dcache_page(page); + flush_dcache_page(page); } if (more && walk->offset >= walk->sg->offset + walk->sg->length) -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 01/18] mm: add a kunmap_local_dirty helper
On Thu, Jun 17, 2021 at 08:01:57PM -0700, Ira Weiny wrote: > > > + flush_kernel_dcache_page(__page); \ > > Is this required on 32bit systems? Why is kunmap_flush_on_unmap() not > sufficient on 64bit systems? The normal kunmap_local() path does that. > > I'm sorry but I did not see a conclusion to my query on V1. Herbert implied > the > he just copied from the crypto code.[1] I'm concerned that this _dirty() call > is just going to confuse the users of kmap even more. So why can't we get to > the bottom of why flush_kernel_dcache_page() needs so much logic around it > before complicating the general kernel users. > > I would like to see it go away if possible. This thread may be related: https://lwn.net/Articles/240249/ Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 04/11] crypto: marvell: cesa: change FPGA indirect article to an
On Tue, Jun 08, 2021 at 02:23:43PM -0700, t...@redhat.com wrote: > From: Tom Rix > > Change use of 'a fpga' to 'an fpga' > > Signed-off-by: Tom Rix > --- > drivers/crypto/marvell/cesa/cesa.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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 09/16] ps3disk: use memcpy_{from,to}_bvec
On Fri, Jun 11, 2021 at 09:07:43PM -0700, Ira Weiny wrote:
>
> More recently this was added:
>
> 7e34e0bbc644 crypto: omap-crypto - fix userspace copied buffer access
>
> I'm CC'ing Tero and Herbert to see why they added the SLAB check.
Probably because the generic Crypto API has the same check. This
all goes back to
commit 4f3e797ad07d52d34983354a77b365dfcd48c1b4
Author: Herbert Xu
Date: Mon Feb 9 14:22:14 2009 +1100
crypto: scatterwalk - Avoid flush_dcache_page on slab pages
It's illegal to call flush_dcache_page on slab pages on a number
of architectures. So this patch avoids doing so if PageSlab is
true.
In future we can move the flush_dcache_page call to those page
cache users that actually need it.
Reported-by: David S. Miller
Signed-off-by: Herbert Xu
But I can't find any emails discussing this so let me ask Dave
directly and see if he can tell us what the issue was or might
have been.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] Rid W=1 warnings from Crypto
On Thu, May 20, 2021 at 10:27:30AM +0100, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Lee Jones (3): > crypto: cavium: Fix a bunch of kernel-doc related issues > crypto: nx: nx-aes-gcm: Kernel-doc formatting should not be used for > headers > crypto: ccp: ccp-dev: Fix a little doc-rot > > drivers/crypto/cavium/cpt/cptpf_main.c| 2 +- > drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 4 ++-- > drivers/crypto/cavium/nitrox/nitrox_main.c| 4 ++-- > drivers/crypto/cavium/nitrox/nitrox_mbx.c | 4 ++-- > drivers/crypto/cavium/nitrox/nitrox_reqmgr.c | 12 ++ > .../crypto/cavium/nitrox/nitrox_skcipher.c| 2 +- > drivers/crypto/ccp/ccp-dev.c | 2 +- > drivers/crypto/nx/nx-842-pseries.c| 24 +-- > 8 files changed, 27 insertions(+), 27 deletions(-) > > Cc: Benjamin Herrenschmidt > Cc: "David S. Miller" > Cc: Gary R Hook > Cc: George Cherian > Cc: Haren Myneni > Cc: Herbert Xu > Cc: John Allen > Cc: linux-cry...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Robert Jennings > Cc: Seth Jennings > Cc: Tom Lendacky > -- > 2.31.1 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 -next] crypto: nx842: add missing MODULE_DEVICE_TABLE
On Sat, May 08, 2021 at 11:14:55AM +0800, Bixuan Cui wrote: > This patch adds missing MODULE_DEVICE_TABLE definition which generates > correct modalias for automatic loading of this driver when it is built > as an external module. > > Reported-by: Hulk Robot > Signed-off-by: Bixuan Cui > --- > drivers/crypto/nx/nx-842-pseries.c | 1 + > 1 file changed, 1 insertion(+) 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: [V3 PATCH 16/16] crypto/nx: Add sysfs interface to export NX capabilities
On Sat, Apr 17, 2021 at 02:13:40PM -0700, Haren Myneni wrote: > > Changes to export the following NXGZIP capabilities through sysfs: > > /sys/devices/vio/ibm,compression-v1/NxGzCaps: > min_compress_len /*Recommended minimum compress length in bytes*/ > min_decompress_len /*Recommended minimum decompress length in bytes*/ > req_max_processed_len /* Maximum number of bytes processed in one > request */ > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/nx-common-pseries.c | 43 +++ > 1 file changed, 43 insertions(+) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [V3 PATCH 15/16] crypto/nx: Get NX capabilities for GZIP coprocessor type
On Sat, Apr 17, 2021 at 02:12:51PM -0700, Haren Myneni wrote: > > phyp provides NX capabilities which gives recommended minimum > compression / decompression length and maximum request buffer size > in bytes. > > Changes to get NX overall capabilities which points to the specific > features phyp supports. Then retrieve NXGZIP specific capabilities. > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/nx-common-pseries.c | 83 +++ > 1 file changed, 83 insertions(+) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [V3 PATCH 14/16] crypto/nx: Register and unregister VAS interface
On Sat, Apr 17, 2021 at 02:12:12PM -0700, Haren Myneni wrote: > > Changes to create /dev/crypto/nx-gzip interface with VAS register > and to remove this interface with VAS unregister. > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/Kconfig | 1 + > drivers/crypto/nx/nx-common-pseries.c | 9 + > 2 files changed, 10 insertions(+) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [V3 PATCH 13/16] crypto/nx: Rename nx-842-pseries file name to nx-common-pseries
On Sat, Apr 17, 2021 at 02:11:15PM -0700, Haren Myneni wrote:
>
> Rename nx-842-pseries.c to nx-common-pseries.c to add code for new
> GZIP compression type. The actual functionality is not changed in
> this patch.
>
> Signed-off-by: Haren Myneni
> ---
> drivers/crypto/nx/Makefile | 2 +-
> drivers/crypto/nx/{nx-842-pseries.c => nx-common-pseries.c} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename drivers/crypto/nx/{nx-842-pseries.c => nx-common-pseries.c} (100%)
>
> diff --git a/drivers/crypto/nx/Makefile b/drivers/crypto/nx/Makefile
> index bc89a20e5d9d..d00181a26dd6 100644
> --- a/drivers/crypto/nx/Makefile
> +++ b/drivers/crypto/nx/Makefile
> @@ -14,5 +14,5 @@ nx-crypto-objs := nx.o \
> obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o
> nx-compress.o
> obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o
> nx-compress.o
> nx-compress-objs := nx-842.o
> -nx-compress-pseries-objs := nx-842-pseries.o
> +nx-compress-pseries-objs := nx-common-pseries.o
> nx-compress-powernv-objs := nx-common-powernv.o
> diff --git a/drivers/crypto/nx/nx-842-pseries.c
> b/drivers/crypto/nx/nx-common-pseries.c
> similarity index 100%
> rename from drivers/crypto/nx/nx-842-pseries.c
> rename to drivers/crypto/nx/nx-common-pseries.c
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: nx: fix incorrect kernel-doc comment syntax in files
On Sun, Mar 21, 2021 at 06:00:07PM +0530, Aditya Srivastava wrote: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > There are certain files in drivers/crypto/nx, which follow this syntax, > but the content inside does not comply with kernel-doc. > Such lines were probably not meant for kernel-doc parsing, but are parsed > due to the presence of kernel-doc like comment syntax(i.e, '/**'), which > causes unexpected warnings from kernel-doc. > > E.g., presence of kernel-doc like comment in the header lines for > drivers/crypto/nx/nx-sha256.c at header causes these warnings: > "warning: Function parameter or member 'tfm' not described in > 'nx_crypto_ctx_sha256_init'" > "warning: expecting prototype for SHA(). Prototype was for > nx_crypto_ctx_sha256_init() instead" > > Similarly for other files too. > > Provide a simple fix by replacing such occurrences with general comment > format, i.e. '/*', to prevent kernel-doc from parsing it. > > Signed-off-by: Aditya Srivastava > --- > * Applies perfectly on next-20210319 > > drivers/crypto/nx/nx-aes-cbc.c | 2 +- > drivers/crypto/nx/nx-aes-ccm.c | 2 +- > drivers/crypto/nx/nx-aes-ctr.c | 2 +- > drivers/crypto/nx/nx-aes-ecb.c | 2 +- > drivers/crypto/nx/nx-aes-gcm.c | 2 +- > drivers/crypto/nx/nx-aes-xcbc.c | 2 +- > drivers/crypto/nx/nx-sha256.c | 2 +- > drivers/crypto/nx/nx-sha512.c | 2 +- > drivers/crypto/nx/nx.c | 2 +- > drivers/crypto/nx/nx_debugfs.c | 2 +- > 10 files changed, 10 insertions(+), 10 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: vmx: fix incorrect kernel-doc comment syntax in files
On Sun, Mar 21, 2021 at 01:55:25AM +0530, Aditya Srivastava wrote: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > There are certain files in drivers/crypto/vmx, which follow this syntax, > but the content inside does not comply with kernel-doc. > Such lines were probably not meant for kernel-doc parsing, but are parsed > due to the presence of kernel-doc like comment syntax(i.e, '/**'), which > causes unexpected warnings from kernel-doc. > > E.g., presence of kernel-doc like comment in the header line for > drivers/crypto/vmx/vmx.c causes this warning by kernel-doc: > > "warning: expecting prototype for Routines supporting VMX instructions on the > Power 8(). Prototype was for p8_init() instead" > > Similarly for other files too. > > Provide a simple fix by replacing such occurrences with general comment > format, i.e. '/*', to prevent kernel-doc from parsing it. > > Signed-off-by: Aditya Srivastava > --- > * Applies perfectly on next-20210319 > > drivers/crypto/vmx/aes.c | 2 +- > drivers/crypto/vmx/aes_cbc.c | 2 +- > drivers/crypto/vmx/aes_ctr.c | 2 +- > drivers/crypto/vmx/aes_xts.c | 2 +- > drivers/crypto/vmx/ghash.c | 2 +- > drivers/crypto/vmx/vmx.c | 2 +- > 6 files changed, 6 insertions(+), 6 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 v3 00/10] Rid W=1 warnings in Crypto
On Thu, Mar 18, 2021 at 12:44:12PM +, Lee Jones wrote: > This is set 1 of 2 sets required to fully clean Crypto. > > v2: No functional changes since v1. > v3: Description change and additional struct header fix > > Lee Jones (10): > crypto: hisilicon: sec_drv: Supply missing description for > 'sec_queue_empty()'s 'queue' param > crypto: bcm: Fix a whole host of kernel-doc misdemeanours > crypto: chelsio: chcr_core: Fix some kernel-doc issues > crypto: ux500: hash: hash_core: Fix worthy kernel-doc headers and > remove others > crypto: keembay: ocs-hcu: Fix incorrectly named functions/structs > crypto: atmel-ecc: Struct headers need to start with keyword 'struct' > crypto: caam: caampkc: Provide the name of the function and provide > missing descriptions > crypto: vmx: Source headers are not good kernel-doc candidates > crypto: nx: nx-aes-cbc: Repair some kernel-doc problems > crypto: cavium: nitrox_isr: Demote non-compliant kernel-doc headers > > drivers/crypto/atmel-ecc.c| 2 +- > drivers/crypto/bcm/cipher.c | 7 ++-- > drivers/crypto/bcm/spu.c | 16 - > drivers/crypto/bcm/spu2.c | 43 +-- > drivers/crypto/bcm/util.c | 4 +-- > drivers/crypto/caam/caamalg_qi2.c | 3 ++ > drivers/crypto/caam/caampkc.c | 3 +- > drivers/crypto/cavium/nitrox/nitrox_isr.c | 4 +-- > drivers/crypto/chelsio/chcr_algo.c| 8 ++--- > drivers/crypto/chelsio/chcr_core.c| 2 +- > drivers/crypto/hisilicon/sec/sec_drv.c| 1 + > drivers/crypto/keembay/ocs-hcu.c | 8 ++--- > drivers/crypto/nx/nx-aes-cbc.c| 2 +- > drivers/crypto/nx/nx.c| 5 +-- > drivers/crypto/nx/nx_debugfs.c| 2 +- > drivers/crypto/ux500/cryp/cryp.c | 5 +-- > drivers/crypto/ux500/cryp/cryp_core.c | 5 +-- > drivers/crypto/ux500/cryp/cryp_irq.c | 2 +- > drivers/crypto/ux500/hash/hash_core.c | 15 +++- > drivers/crypto/vmx/vmx.c | 2 +- > 20 files changed, 73 insertions(+), 66 deletions(-) > > Cc: Alexandre Belloni > Cc: Andreas Westin > Cc: Atul Gupta > Cc: Aymen Sghaier > Cc: Ayush Sawal > Cc: Benjamin Herrenschmidt > Cc: Berne Hebark > Cc: "Breno Leitão" > Cc: Daniele Alessandrelli > Cc: "David S. Miller" > Cc: Declan Murphy > Cc: Harsh Jain > Cc: Henrique Cerri > Cc: Herbert Xu > Cc: "Horia Geantă" > Cc: Jitendra Lulla > Cc: Joakim Bech > Cc: Jonas Linde > Cc: Jonathan Cameron > Cc: Kent Yoder > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-cry...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Ludovic Desroches > Cc: Manoj Malviya > Cc: Michael Ellerman > Cc: M R Gowda > Cc: Nayna Jain > Cc: Nicolas Ferre > Cc: Niklas Hernaeus > Cc: Paul Mackerras > Cc: Paulo Flabiano Smorigo > Cc: Rob Rice > Cc: Rohit Maheshwari > Cc: Shujuan Chen > Cc: Tudor Ambarus > Cc: Vinay Kumar Yadav > Cc: Zaibo Xu All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: sha: remove unneeded semicolon
On Mon, Feb 08, 2021 at 05:10:38PM +0800, Yang Li wrote: > Eliminate the following coccicheck warning: > ./arch/powerpc/crypto/sha1-spe-glue.c:110:2-3: Unneeded semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > arch/powerpc/crypto/sha1-spe-glue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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/nx: add missing call to of_node_put()
On Fri, Feb 26, 2021 at 09:23:06AM +0800, Yang Li wrote: > In one of the error paths of the for_each_child_of_node() loop, > add missing call to of_node_put(). > > Fix the following coccicheck warning: > ./drivers/crypto/nx/nx-common-powernv.c:927:1-23: WARNING: Function > "for_each_child_of_node" should have of_node_put() before return around > line 936. > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > > Changes in v2: > -add braces for if > > drivers/crypto/nx/nx-common-powernv.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) 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: powerpc: remove unneeded semicolon
On Tue, Feb 02, 2021 at 11:17:30AM +0800, Yang Li wrote: > Eliminate the following coccicheck warning: > ./arch/powerpc/crypto/sha256-spe-glue.c:132:2-3: Unneeded > semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > arch/powerpc/crypto/sha256-spe-glue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/20] Rid W=1 warnings in Crypto
On Thu, Feb 04, 2021 at 11:09:40AM +, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > This is set 1 of 2 sets required to fully clean Crypto. > > Lee Jones (20): > crypto: hisilicon: sec_drv: Supply missing description for > 'sec_queue_empty()'s 'queue' param > crypto: bcm: util: Repair a couple of documentation formatting issues > crypto: chelsio: chcr_core: File headers are not good candidates for > kernel-doc > crypto: ux500: hash: hash_core: Fix worthy kernel-doc headers and > remove others > crypto: bcm: spu: Fix formatting and misspelling issues > crypto: keembay: ocs-hcu: Fix incorrectly named functions/structs > crypto: bcm: spu2: Fix a whole host of kernel-doc misdemeanours > crypto: ux500: cryp: Demote some conformant non-kernel headers fix > another > crypto: ux500: cryp_irq: File headers are not good kernel-doc > candidates > crypto: chelsio: chcr_algo: Fix a couple of kernel-doc issues caused > by doc-rot > crypto: ux500: cryp_core: Fix formatting issue and add description for > 'session_id' > crypto: atmel-ecc: Struct headers need to start with keyword 'struct' > crypto: bcm: cipher: Provide description for 'req' and fix formatting > issues > crypto: caam: caampkc: Provide the name of the function > crypto: caam: caamalg_qi2: Supply a couple of 'fallback' related > descriptions > crypto: vmx: Source headers are not good kernel-doc candidates > crypto: nx: nx-aes-cbc: Headers comments should not be kernel-doc > crypto: nx: nx_debugfs: Header comments should not be kernel-doc > crypto: nx: Demote header comment and add description for 'nbytes' > crypto: cavium: nitrox_isr: Demote non-compliant kernel-doc headers Thanks for doing this. But please don't split the patches at the file level. Instead split them at the driver level. For example, all of your bcm changes should be one patch. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error)
On Wed, Jan 20, 2021 at 06:57:24PM +, Christophe Leroy wrote:
> Talitos Security Engine AESU considers any input
> data size that is not a multiple of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size.
>
> Test Manager for ctr(aes) fails on 4th test vector which has
> a length of 499 while all previous vectors which have a 16 bytes
> multiple length succeed.
>
> As suggested by Freescale, round up the input data length to the
> nearest 16 bytes.
>
> Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 28
> drivers/crypto/talitos.h | 1 +
> 2 files changed, 17 insertions(+), 12 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: talitos - Fix return type of current_desc_hdr()
On Thu, Oct 08, 2020 at 09:34:56AM +, Christophe Leroy wrote:
> current_desc_hdr() returns a u32 but in fact this is a __be32,
> leading to a lot of sparse warnings.
>
> Change the return type to __be32 and ensure it is handled as
> sure by the caller.
>
> Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error
> path")
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 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: talitos - Endianess in current_desc_hdr()
On Thu, Oct 08, 2020 at 09:34:55AM +, Christophe Leroy wrote:
> current_desc_hdr() compares the value of the current descriptor
> with the next_desc member of the talitos_desc struct.
>
> While the current descriptor is obtained from in_be32() which
> return CPU ordered bytes, next_desc member is in big endian order.
>
> Convert the current descriptor into big endian before comparing it
> with next_desc.
>
> This fixes a sparse warning.
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
> SEC1")
> Signed-off-by: Christophe Leroy
> ---
> drivers/crypto/talitos.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 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: talitos - Fix sparse warnings
On Sat, Oct 03, 2020 at 07:15:53PM +0200, Christophe Leroy wrote: > > The following changes fix the sparse warnings with less churn: Yes that works too. Can you please submit 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] soc: fsl: Remove bogus packed attributes from qman.h
On Tue, Sep 01, 2020 at 04:40:16PM -0500, Li Yang wrote: > > Looks like the CAAM driver and dependent QBMAN driver doesn't support > COMPILE_TEST yet. Are you trying to add the support for it? Yes. > I think this is a valid concern that if the parent structure doesn't > meet certain alignment requirements, the alignment for the > sub-structure cannot be guaranteed. If we just remove the __packed > attribute from the parent structure, the compiler could try to add > padding in the parent structure to fulfill the alignment requirements > of the sub structure which is not good. I think the following changes > are a better fix for the warnings: This works for me. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] soc: fsl: Remove bogus packed attributes from qman.h
On Tue, Sep 01, 2020 at 01:50:38AM +, Leo Li wrote: > > Sorry for the late response. I missed this email previously. > > These structures are descriptors used by hardware, we cannot have _ANY_ > padding from the compiler. The compiled result might be the same with or > without the __packed attribute for now, but I think keep it there probably is > safer for dealing with unexpected alignment requirements from the compiler in > the future. > > Having conflicting alignment requirements warning might means something is > wrong with the structure in certain scenario. I just tried a ARM64 build but > didn't see the warnings. Could you share the warning you got and the build > setup? Thanks. Just do a COMPILE_TEST build on x86-64: In file included from ../drivers/crypto/caam/qi.c:12: ../include/soc/fsl/qman.h:259:1: warning: alignment 1 of ‘struct qm_dqrr_entry’ is less than 8 [-Wpacked-not-aligned] } __packed; ^ ../include/soc/fsl/qman.h:292:2: warning: alignment 1 of ‘struct ’ is less than 8 [-Wpacked-not-aligned] } __packed ern; ^ In any case, those packed markers are completely unnecessary because those structs contain no holes. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] soc: fsl: Remove bogus packed attributes from qman.h
On Thu, Jul 30, 2020 at 10:52:59PM +1000, Herbert Xu wrote: > There are two __packed attributes in qman.h that are both unnecessary > and causing compiler warnings because they're conflicting with > explicit alignment requirements set on members within the structure. > > This patch removes them both. > > Signed-off-by: Herbert Xu Ping. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
On Tue, Aug 11, 2020 at 06:28:39PM +0300, Horia Geantă wrote: > > What about, for example, CBC? > AFAICT cbc(aes) with input length = 0 is valid. That's just because CBC accepts any input which is a multiple of blocksize. > Same for CTR (with the note that blocksize = 1) and several other algorithms > mentioned in the cover letter. CTR accepts any input size. > What's the rule in these cases? What input size is accepted depends on the algorithm. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero
On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote: > > With all due respect, but this makes no sense. I agree. This is a lot of churn for no gain. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] soc: fsl: Remove bogus packed attributes from qman.h
There are two __packed attributes in qman.h that are both unnecessary
and causing compiler warnings because they're conflicting with
explicit alignment requirements set on members within the structure.
This patch removes them both.
Signed-off-by: Herbert Xu
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index cfe00e08e85b..d81ff185dc0b 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -256,7 +256,7 @@ struct qm_dqrr_entry {
__be32 context_b;
struct qm_fd fd;
u8 __reserved4[32];
-} __packed;
+};
#define QM_DQRR_VERB_VBIT 0x80
#define QM_DQRR_VERB_MASK 0x7f/* where the verb contains; */
#define QM_DQRR_VERB_FRAME_DEQUEUE 0x60/* "this format" */
@@ -289,7 +289,7 @@ union qm_mr_entry {
__be32 tag;
struct qm_fd fd;
u8 __reserved1[32];
- } __packed ern;
+ } ern;
struct {
u8 verb;
u8 fqs; /* Frame Queue Status */
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[v2 PATCH] crypto: af_alg - Fix regression on empty requests
On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
>
> Since we are on this subject,
> LTP af_alg02 test case fails on stable 4.9 and stable 4.4
> This is not a regression because the test case has been failing from
> the beginning.
>
> Is this test case expected to fail on stable 4.9 and 4.4 ?
> or any chance to fix this on these older branches ?
>
> Test output:
> af_alg02.c:52: BROK: Timed out while reading from request socket.
>
> ref:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884917/suite/ltp-crypto-tests/test/af_alg02/history/
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884606/suite/ltp-crypto-tests/test/af_alg02/log
Actually this test really is broken. Even though empty requests
are legal, they should never be done with no write(2) at all.
Because this fundamentally breaks the use of a blocking read(2)
to wait for more data.
Granted this has been broken since 2017 but I'm not going to
reintroduce this just because of a broken test case.
So please either remove af_alg02 or fix it by adding a control
message through sendmsg(2).
Thanks,
---8<---
Some user-space programs rely on crypto requests that have no
control metadata. This broke when a check was added to require
the presence of control metadata with the ctx->init flag.
This patch fixes the regression by setting ctx->init as long as
one sendmsg(2) has been made, with or without a control message.
Reported-by: Sachin Sant
Reported-by: Naresh Kamboju
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 9fcb91ea10c41..5882ed46f1adb 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -851,6 +851,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
err = -EINVAL;
goto unlock;
}
+ ctx->init = true;
if (init) {
ctx->enc = enc;
@@ -858,7 +859,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
memcpy(ctx->iv, con.iv->iv, ivsize);
ctx->aead_assoclen = con.aead_assoclen;
- ctx->init = true;
}
while (size) {
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: af_alg - Fix regression on empty requests
On Tue, Jun 23, 2020 at 10:02:17AM -0700, Eric Biggers wrote:
>
> The source code for the two failing AF_ALG tests is here:
>
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg02.c
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg05.c
>
> They use read() and write(), not send() and recv().
>
> af_alg02 uses read() to read from a "salsa20" request socket without writing
> anything to it. It is expected that this returns 0, i.e. that behaves like
> encrypting an empty message.
>
> af_alg05 uses write() to write 15 bytes to a "cbc(aes-generic)" request
> socket,
> then read() to read 15 bytes. It is expected that this fails with EINVAL,
> since
> the length is not aligned to the AES block size (16 bytes).
This patch should fix the regression:
---8<---
Some user-space programs rely on crypto requests that have no
control metadata. This broke when a check was added to require
the presence of control metadata with the ctx->init flag.
This patch fixes the regression by removing the ctx->init flag.
This means that we do not distinguish the case of no metadata
as opposed to an empty request. IOW it is always assumed that
if you call recv(2) before sending metadata that you are working
with an empty request.
Reported-by: Sachin Sant
Reported-by: Naresh Kamboju
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 9fcb91ea10c4..2d391117c020 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -635,7 +635,6 @@ void af_alg_pull_tsgl(struct sock *sk, size_t used, struct
scatterlist *dst,
if (!ctx->used)
ctx->merge = 0;
- ctx->init = ctx->more;
}
EXPORT_SYMBOL_GPL(af_alg_pull_tsgl);
@@ -757,8 +756,7 @@ int af_alg_wait_for_data(struct sock *sk, unsigned flags,
unsigned min)
break;
timeout = MAX_SCHEDULE_TIMEOUT;
if (sk_wait_event(sk, ,
- ctx->init && (!ctx->more ||
- (min && ctx->used >= min)),
+ !ctx->more || (min && ctx->used >= min),
)) {
err = 0;
break;
@@ -847,7 +845,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
}
lock_sock(sk);
- if (ctx->init && (init || !ctx->more)) {
+ if (!ctx->more && ctx->used) {
err = -EINVAL;
goto unlock;
}
@@ -858,7 +856,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
memcpy(ctx->iv, con.iv->iv, ivsize);
ctx->aead_assoclen = con.aead_assoclen;
- ctx->init = true;
}
while (size) {
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index d48d2156e621..749fe42315be 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -106,7 +106,7 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr
*msg,
size_t usedpages = 0; /* [in] RX bufs to be used from user */
size_t processed = 0; /* [in] TX bufs to be consumed */
- if (!ctx->init || ctx->more) {
+ if (ctx->more) {
err = af_alg_wait_for_data(sk, flags, 0);
if (err)
return err;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index a51ba22fef58..5b6fa5e8c00d 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -61,7 +61,7 @@ static int _skcipher_recvmsg(struct socket *sock, struct
msghdr *msg,
int err = 0;
size_t len = 0;
- if (!ctx->init || (ctx->more && ctx->used < bs)) {
+ if (ctx->more && ctx->used < bs) {
err = af_alg_wait_for_data(sk, flags, bs);
if (err)
return err;
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index ee6412314f8f..08c087cc89d6 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -135,7 +135,6 @@ struct af_alg_async_req {
* SG?
* @enc: Cryptographic operation to be performed when
* recvmsg is invoked.
- * @init: True if metadata has been sent.
* @len: Length of memory allocated for this data structure.
*/
struct af_alg_ctx {
@@ -152,7 +151,6 @@ struct af_alg_ctx {
bool more;
bool merge;
bool enc;
- bool init;
unsigned int len;
};
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [next-20200621] LTP tests af_alg02/05 failure on POWER9 PowerVM LPAR
On Mon, Jun 22, 2020 at 05:55:29PM +0530, Sachin Sant wrote: > With recent next(next-20200621) af_alg02/05 tests fail while running on POWER9 > PowerVM LPAR. > > Results from 5.8.0-rc1-next-20200622 > # ./af_alg02 > tst_test.c:1096: INFO: Timeout per run is 0h 00m 20s > af_alg02.c:52: BROK: Timed out while reading from request socket. > # > > 5.8.0-rc1-next-20200618 was good. The test case ran fine. > > Root cause analysis point to following commit: > > commit f3c802a1f30013f8f723b62d7fa49eb9e991da23 > crypto: algif_aead - Only wake up when ctx->more is zero > > Reverting this commit allows the test to PASS. Yes that commit does change the behaviour if you don't terminate your AEAD request by clearing the MSG_MORE flag. AEAD does not support chaining so each request must be sent in full before it can be processed through recvmsg(2). Setting the MSG_MORE flag indicates that your request has not been sent in full. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/7] sha1 library cleanup
Eric Biggers wrote: > sounds very generic and important, like it's the > header to include if you're doing cryptographic hashing in the kernel. > But actually it only includes the library implementation of the SHA-1 > compression function (not even the full SHA-1). This should basically > never be used anymore; SHA-1 is no longer considered secure, and there > are much better ways to do cryptographic hashing in the kernel. > > Also the function is named just "sha_transform()", which makes it > unclear which version of SHA is meant. > > Therefore, this series cleans things up by moving these SHA-1 > declarations into where they better belong, and changing > the names to say SHA-1 rather than just SHA. > > As future work, we should split sha.h into sha1.h and sha2.h and try to > remove the remaining uses of SHA-1. For example, the remaining use in > drivers/char/random.c is probably one that can be gotten rid of. > > This patch series applies to cryptodev/master. > > Eric Biggers (7): > mptcp: use SHA256_BLOCK_SIZE, not SHA_MESSAGE_BYTES > crypto: powerpc/sha1 - remove unused temporary workspace > crypto: powerpc/sha1 - prefix the "sha1_" functions > crypto: s390/sha1 - prefix the "sha1_" functions > crypto: lib/sha1 - rename "sha" to "sha1" > crypto: lib/sha1 - remove unnecessary includes of linux/cryptohash.h > crypto: lib/sha1 - fold linux/cryptohash.h into crypto/sha.h > > Documentation/security/siphash.rst | 2 +- > arch/arm/crypto/sha1_glue.c | 1 - > arch/arm/crypto/sha1_neon_glue.c| 1 - > arch/arm/crypto/sha256_glue.c | 1 - > arch/arm/crypto/sha256_neon_glue.c | 1 - > arch/arm/kernel/armksyms.c | 1 - > arch/arm64/crypto/sha256-glue.c | 1 - > arch/arm64/crypto/sha512-glue.c | 1 - > arch/microblaze/kernel/microblaze_ksyms.c | 1 - > arch/mips/cavium-octeon/crypto/octeon-md5.c | 1 - > arch/powerpc/crypto/md5-glue.c | 1 - > arch/powerpc/crypto/sha1-spe-glue.c | 1 - > arch/powerpc/crypto/sha1.c | 33 ++--- > arch/powerpc/crypto/sha256-spe-glue.c | 1 - > arch/s390/crypto/sha1_s390.c| 12 > arch/sparc/crypto/md5_glue.c| 1 - > arch/sparc/crypto/sha1_glue.c | 1 - > arch/sparc/crypto/sha256_glue.c | 1 - > arch/sparc/crypto/sha512_glue.c | 1 - > arch/unicore32/kernel/ksyms.c | 1 - > arch/x86/crypto/sha1_ssse3_glue.c | 1 - > arch/x86/crypto/sha256_ssse3_glue.c | 1 - > arch/x86/crypto/sha512_ssse3_glue.c | 1 - > crypto/sha1_generic.c | 5 ++-- > drivers/char/random.c | 8 ++--- > drivers/crypto/atmel-sha.c | 1 - > drivers/crypto/chelsio/chcr_algo.c | 1 - > drivers/crypto/chelsio/chcr_ipsec.c | 1 - > drivers/crypto/omap-sham.c | 1 - > fs/f2fs/hash.c | 1 - > include/crypto/sha.h| 10 +++ > include/linux/cryptohash.h | 14 - > include/linux/filter.h | 4 +-- > include/net/tcp.h | 1 - > kernel/bpf/core.c | 18 +-- > lib/crypto/chacha.c | 1 - > lib/sha1.c | 24 --- > net/core/secure_seq.c | 1 - > net/ipv6/addrconf.c | 10 +++ > net/ipv6/seg6_hmac.c| 1 - > net/mptcp/crypto.c | 4 +-- > 41 files changed, 69 insertions(+), 104 deletions(-) > delete mode 100644 include/linux/cryptohash.h > > > base-commit: 12b3cf9093542d9f752a4968815ece836159013f 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] lib/mpi: Fix building for powerpc with clang
On Mon, Apr 13, 2020 at 12:50:42PM -0700, Nathan Chancellor wrote:
> 0day reports over and over on an powerpc randconfig with clang:
>
> lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast or build with
> -fheinous-gnu-extensions
>
> Remove the superfluous casts, which have been done previously for x86
> and arm32 in commit dea632cadd12 ("lib/mpi: fix build with clang") and
> commit 7b7c1df2883d ("lib/mpi/longlong.h: fix building with 32-bit
> x86").
>
> Reported-by: kbuild test robot
> Link: https://github.com/ClangBuiltLinux/linux/issues/991
> Signed-off-by: Nathan Chancellor
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 8/9] crypto/nx: Remove 'pid' in vas_tx_win_attr struct
On Sun, Mar 22, 2020 at 09:06:17PM -0700, Haren Myneni wrote: > > When window is opened, pid reference is taken for user space > windows. Not needed for kernel windows. So remove 'pid' in > vas_tx_win_attr struct. > > Signed-off-by: Haren Myneni > --- > arch/powerpc/include/asm/vas.h| 1 - > drivers/crypto/nx/nx-common-powernv.c | 1 - > 2 files changed, 2 deletions(-) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 7/9] crypto/nx: Enable and setup GZIP compression type
On Sun, Mar 22, 2020 at 09:05:37PM -0700, Haren Myneni wrote: > > Changes to probe GZIP device-tree nodes, open RX windows and setup > GZIP compression type. No plans to provide GZIP usage in kernel right > now, but this patch enables GZIP for user space usage. > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/nx-common-powernv.c | 43 > ++- > 1 file changed, 37 insertions(+), 6 deletions(-) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 6/9] crypto/NX: Make enable code generic to add new GZIP compression type
On Sun, Mar 22, 2020 at 09:04:47PM -0700, Haren Myneni wrote: > > Make setup and enable code generic to support new GZIP compression type. > Changed nx842 reference to nx and moved some code to new functions. > Functionality is not changed except sparse warning fix - setting NULL > instead of 0 for per_cpu send window in nx_delete_coprocs(). > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/nx-common-powernv.c | 161 > +- > 1 file changed, 101 insertions(+), 60 deletions(-) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 5/9] crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
On Sun, Mar 22, 2020 at 09:03:50PM -0700, Haren Myneni wrote: > > Rename nx-842-powernv.c to nx-common-powernv.c to add code for setup > and enable new GZIP compression type. The actual functionality is not > changed in this patch. > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/Makefile|2 +- > drivers/crypto/nx/nx-842-powernv.c| 1062 > - > drivers/crypto/nx/nx-common-powernv.c | 1062 > + > 3 files changed, 1063 insertions(+), 1063 deletions(-) > delete mode 100644 drivers/crypto/nx/nx-842-powernv.c > create mode 100644 drivers/crypto/nx/nx-common-powernv.c Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 4/9] crypto/nx: Initialize coproc entry with kzalloc
On Sun, Mar 22, 2020 at 09:03:00PM -0700, Haren Myneni wrote: > > coproc entry is initialized during NX probe on power9, but not on P8. > nx842_delete_coprocs() is used for both and frees receive window if it > is allocated. Getting crash for rmmod on P8 since coproc->vas.rxwin > is not initialized. > > This patch replaces kmalloc with kzalloc in nx842_powernv_probe() > > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/nx-842-powernv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: Replace zero-length array with flexible-array member
On Mon, Feb 24, 2020 at 10:21:00AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/crypto/caam/caamalg.c | 2 +-
> drivers/crypto/caam/caamalg_qi.c | 4 ++--
> drivers/crypto/caam/caamalg_qi2.h | 6 +++---
> drivers/crypto/caam/caamhash.c | 2 +-
> drivers/crypto/cavium/nitrox/nitrox_main.c | 2 +-
> drivers/crypto/chelsio/chcr_core.h | 2 +-
> drivers/crypto/mediatek/mtk-sha.c | 2 +-
> drivers/crypto/nx/nx.h | 2 +-
> drivers/crypto/omap-sham.c | 4 ++--
> include/crypto/if_alg.h| 2 +-
> 10 files changed, 14 insertions(+), 14 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: vmx/xts - reject inputs that are too short
On Wed, Jan 08, 2020 at 04:06:46PM +1100, Daniel Axtens wrote:
> When the kernel XTS implementation was extended to deal with ciphertext
> stealing in commit 8083b1bf8163 ("crypto: xts - add support for ciphertext
> stealing"), a check was added to reject inputs that were too short.
>
> However, in the vmx enablement - commit 239668419349 ("crypto: vmx/xts -
> use fallback for ciphertext stealing"), that check wasn't added to the
> vmx implementation. This disparity leads to errors like the following:
>
> alg: skcipher: p8_aes_xts encryption unexpectedly succeeded on test vector
> "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace may_sleep
> use_finup src_divs=[66.99%@+10, 33.1%@alignmask+1155]"
>
> Return -EINVAL if asked to operate with a cryptlen smaller than the AES
> block size. This brings vmx in line with the generic implementation.
>
> Reported-by: Erhard Furtner
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206049
> Fixes: 239668419349 ("crypto: vmx/xts - use fallback for ciphertext stealing")
> Cc: Ard Biesheuvel
> Cc: sta...@vger.kernel.org # v5.4+
> Signed-off-by: Michael Ellerman
> [dja: commit message]
> Signed-off-by: Daniel Axtens
> ---
> drivers/crypto/vmx/aes_xts.c | 3 +++
> 1 file changed, 3 insertions(+)
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 08/10] crypto/NX: Add NX GZIP user space API
On Thu, Dec 19, 2019 at 12:49:44AM -0800, Haren Myneni wrote: > > Virtual Accelerator Switchboard (VAS) can provide support different > accelerators, Right now only NX is used, but possible to extend to > others in future. Or different functionalities such as fast thread > wakeup (VAS feature) with VAS windows. > > So looking common VAS API for any its accelerators. Need open a window / > channel - open() and ioctl()) calls, and setup the communications with > mapping address to NX (mmap()) and close the window. Then user space > communicates to accelerator directly without kernel involvement. > Specific drivers should set window attributes such as how many requests > can be send at same time and etc. All other interfaces should be same > for any accelerator. > > Also, since user space sends requests directly, should restrict > malicious users to prevent overload NX (security issue). Allowing > sysadmin to restrict /dev/crypto/nx-gzip usage. If you are going to place your driver through the Crypto API then it needs to use the Crypto API interface for user-space access. That interface is af_alg. If this is not a good fit then I suggest that you move your API elsewhere, perhaps to the powerpc tree where the user-space API can then be properly reviewed. It is not feasible to review your driver's user-space API through the crypto tree. > As you suggested, SW crypto API (af_alg) can be used just for NX > compression like using API based on the accelerator functionalities. It > is socket based API with AF_ALG socket family. But is there a way for > sysadmin to restrict usage from user space? Need just few functions in > struct proto. The af_alg interface does not operate in the manner that you describe. It is an interface that maps onto the underlying kernel Crypto API operations. We currently don't have an af_alg module for compression, but if we did we would be closely following the current kernel compression interface. One key feature of af_alg is that it normally is agnostic to the underlying implementation. That is, even when the hardware is absent it would seamlessly switch over to a software implementation. I say normally because there can be exceptions, e.g., with paes and hardware keys. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 08/10] crypto/NX: Add NX GZIP user space API
On Sun, Dec 15, 2019 at 05:05:19AM -0800, Haren Myneni wrote: > > On power9, userspace can send GZIP compression requests directly to NX > once kernel establishes NX channel / window. This patch provides GZIP > engine access to user space via /dev/crypto/nx-gzip device node with > open, VAS_TX_WIN_OPEN ioctl, mmap and close operations. > > Each window corresponds to file descriptor and application can open > multiple windows. After the window is opened, mmap() system call to map > the hardware address of engine's request queue into the application's > virtual address space. > > Then the application can then submit one or more requests to the the > engine by using the copy/paste instructions and pasting the CRBs to > the virtual address (aka paste_address) returned by mmap(). > > Signed-off-by: Sukadev Bhattiprolu > Signed-off-by: Haren Myneni > --- > drivers/crypto/nx/Makefile| 2 +- > drivers/crypto/nx/nx-842-powernv.h| 2 + > drivers/crypto/nx/nx-commom-powernv.c | 21 ++- > drivers/crypto/nx/nx-gzip-powernv.c | 282 > ++ > 4 files changed, 304 insertions(+), 3 deletions(-) > create mode 100644 drivers/crypto/nx/nx-gzip-powernv.c We already have a kernel compress API which could be exposed to user-space through af_alg. If every driver created their own user-space API it would be unmanageable. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: vmx - Avoid weird build failures
On Wed, Nov 20, 2019 at 10:27:38PM +1100, Michael Ellerman wrote: > In the vmx crypto Makefile we assign to a variable called TARGET and > pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts. > > The variable is meant to describe what flavour of powerpc we're > building for, eg. either 32 or 64-bit, and big or little endian. > > Unfortunately TARGET is a fairly common name for a make variable, and > if it happens that TARGET is specified as a command line parameter to > make, the value specified on the command line will override our value. > > In particular this can happen if the kernel Makefile is driven by an > external Makefile that uses TARGET for something. > > This leads to weird build failures, eg: > nonsense at /build/linux/drivers/crypto/vmx/ghashp8-ppc.pl line 45. > /linux/drivers/crypto/vmx/Makefile:20: recipe for target > 'drivers/crypto/vmx/ghashp8-ppc.S' failed > > Which shows that we passed an empty value for $(TARGET) to the perl > script, confirmed with make V=1: > > perl /linux/drivers/crypto/vmx/ghashp8-ppc.pl > > drivers/crypto/vmx/ghashp8-ppc.S > > We can avoid this confusion by using override, to tell make that we > don't want anything to override our variable, even a value specified > on the command line. We can also use a less common name, given the > script calls it "flavour", let's use that. > > Signed-off-by: Michael Ellerman > --- > drivers/crypto/vmx/Makefile | 6 +++--- > 1 file changed, 3 insertions(+), 3 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 1/5] crypto: nx - Improve debugfs_create_u{32,64}() handling for atomics
On Mon, Oct 21, 2019 at 04:51:45PM +0200, Geert Uytterhoeven wrote:
> Variables of type atomic{,64}_t can be used fine with
> debugfs_create_u{32,64}, when passing a pointer to the embedded counter.
> This allows to get rid of the casts, which prevented compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/crypto/nx/nx_debugfs.c | 18 +-
> 1 file changed, 9 insertions(+), 9 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 0/3] crypto: powerpc - convert SPE AES algorithms to skcipher API
On Mon, Oct 14, 2019 at 07:45:14PM -0700, Eric Biggers wrote: > This series converts the glue code for the PowerPC SPE implementations > of AES-ECB, AES-CBC, AES-CTR, and AES-XTS from the deprecated > "blkcipher" API to the "skcipher" API. This is needed in order for the > blkcipher API to be removed. > > Patch 1-2 are fixes. Patch 3 is the actual conversion. > > Tested with: > > export ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- > make mpc85xx_defconfig > cat >> .config << EOF > # CONFIG_MODULES is not set > # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set > CONFIG_DEBUG_KERNEL=y > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y > CONFIG_CRYPTO_AES=y > CONFIG_CRYPTO_CBC=y > CONFIG_CRYPTO_CTR=y > CONFIG_CRYPTO_ECB=y > CONFIG_CRYPTO_XTS=y > CONFIG_CRYPTO_AES_PPC_SPE=y > EOF > make olddefconfig > make -j32 > qemu-system-ppc -M mpc8544ds -cpu e500 -nographic \ > -kernel arch/powerpc/boot/zImage \ > -append cryptomgr.fuzz_iterations=1000 > > Note that xts-ppc-spe still fails the comparison tests due to the lack > of ciphertext stealing support. This is not addressed by this series. > > Changed since v1: > > - Split fixes into separate patches. > > - Made ppc_aes_setkey_skcipher() call ppc_aes_setkey(), rather than > creating a separate expand_key() function. This keeps the code > shorter. > > Eric Biggers (3): > crypto: powerpc - don't unnecessarily use atomic scatterwalk > crypto: powerpc - don't set ivsize for AES-ECB > crypto: powerpc - convert SPE AES algorithms to skcipher API > > arch/powerpc/crypto/aes-spe-glue.c | 389 ++++++++- > crypto/Kconfig | 1 + > 2 files changed, 166 insertions(+), 224 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 -next 00/13] hwrng: use devm_platform_ioremap_resource() to simplify code
On Wed, Oct 16, 2019 at 06:46:08PM +0800, YueHaibing wrote: > devm_platform_ioremap_resource() internally have platform_get_resource() > and devm_ioremap_resource() in it. So instead of calling them separately > use devm_platform_ioremap_resource() directly. > > YueHaibing (13): > hwrng: atmel - use devm_platform_ioremap_resource() to simplify code > hwrng: bcm2835 - use devm_platform_ioremap_resource() to simplify code > hwrng: exynos - use devm_platform_ioremap_resource() to simplify code > hwrng: hisi - use devm_platform_ioremap_resource() to simplify code > hwrng: ks-sa - use devm_platform_ioremap_resource() to simplify code > hwrng: meson - use devm_platform_ioremap_resource() to simplify code > hwrng: npcm - use devm_platform_ioremap_resource() to simplify code > hwrng: omap - use devm_platform_ioremap_resource() to simplify code > hwrng: pasemi - use devm_platform_ioremap_resource() to simplify code > hwrng: pic32 - use devm_platform_ioremap_resource() to simplify code > hwrng: st - use devm_platform_ioremap_resource() to simplify code > hwrng: tx4939 - use devm_platform_ioremap_resource() to simplify code > hwrng: xgene - use devm_platform_ioremap_resource() to simplify code > > drivers/char/hw_random/atmel-rng.c | 4 +--- > drivers/char/hw_random/bcm2835-rng.c | 5 + > drivers/char/hw_random/exynos-trng.c | 4 +--- > drivers/char/hw_random/hisi-rng.c| 4 +--- > drivers/char/hw_random/ks-sa-rng.c | 4 +--- > drivers/char/hw_random/meson-rng.c | 4 +--- > drivers/char/hw_random/npcm-rng.c| 4 +--- > drivers/char/hw_random/omap-rng.c| 4 +--- > drivers/char/hw_random/pasemi-rng.c | 4 +--- > drivers/char/hw_random/pic32-rng.c | 4 +--- > drivers/char/hw_random/st-rng.c | 4 +--- > drivers/char/hw_random/tx4939-rng.c | 4 +--- > drivers/char/hw_random/xgene-rng.c | 4 +--- > 13 files changed, 13 insertions(+), 40 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: nx - convert to skcipher API
On Sat, Oct 12, 2019 at 09:39:14PM -0700, Eric Biggers wrote: > This series converts the PowerPC Nest (NX) implementations of AES modes > from the deprecated "blkcipher" API to the "skcipher" API. This is > needed in order for the blkcipher API to be removed. > > This patchset is compile-tested only, as I don't have this hardware. > If anyone has this hardware, please test this patchset with > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y. > > Eric Biggers (4): > crypto: nx - don't abuse blkcipher_desc to pass iv around > crypto: nx - convert AES-ECB to skcipher API > crypto: nx - convert AES-CBC to skcipher API > crypto: nx - convert AES-CTR to skcipher API > > drivers/crypto/nx/nx-aes-cbc.c | 81 ++- > drivers/crypto/nx/nx-aes-ccm.c | 40 ++-- > drivers/crypto/nx/nx-aes-ctr.c | 87 +++--- > drivers/crypto/nx/nx-aes-ecb.c | 76 + > drivers/crypto/nx/nx-aes-gcm.c | 24 -- > drivers/crypto/nx/nx.c | 64 ++--- > drivers/crypto/nx/nx.h | 19 > 7 files changed, 176 insertions(+), 215 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: talitos - fix hash result for VMAP_STACK
On Tue, Sep 10, 2019 at 06:04:14AM +, Christophe Leroy wrote: > When VMAP_STACK is selected, stack cannot be DMA-mapped. > Therefore, the hash result has to be DMA-mapped in the request > context and copied into areq->result at completion. > > Signed-off-by: Christophe Leroy > --- > drivers/crypto/talitos.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) 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 -next] crypto: nx - remove unused variables 'nx_driver_string' and 'nx_driver_version'
On Thu, Aug 22, 2019 at 10:46:49PM +0800, YueHaibing wrote: > drivers/crypto/nx/nx.h:12:19: warning: > nx_driver_string defined but not used [-Wunused-const-variable=] > drivers/crypto/nx/nx.h:13:19: warning: > nx_driver_version defined but not used [-Wunused-const-variable=] > > They are never used, so just remove it. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing > --- > drivers/crypto/nx/nx.h | 3 --- > 1 file changed, 3 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: vmx/xts - use fallback for ciphertext stealing
On Fri, Aug 16, 2019 at 05:06:24PM +0300, Ard Biesheuvel wrote: > For correctness and compliance with the XTS-AES specification, we are > adding support for ciphertext stealing to XTS implementations, even > though no use cases are known that will be enabled by this. > > Since the Power8 implementation already has a fallback skcipher standby > for other purposes, let's use it for this purpose as well. If ciphertext > stealing use cases ever become a bottleneck, we can always revisit this. > > Signed-off-by: Ard Biesheuvel > --- > drivers/crypto/vmx/aes_xts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) 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] hwrng: Use device-managed registration API
On Thu, Jul 25, 2019 at 04:01:55PM +0800, Chuhong Yuan wrote: > Use devm_hwrng_register to simplify the implementation. > Manual unregistration and some remove functions can be > removed now. > > Signed-off-by: Chuhong Yuan > --- > drivers/char/hw_random/atmel-rng.c | 3 +-- > drivers/char/hw_random/cavium-rng-vf.c | 11 +-- > drivers/char/hw_random/exynos-trng.c | 3 +-- > drivers/char/hw_random/n2-drv.c| 4 +--- > drivers/char/hw_random/nomadik-rng.c | 3 +-- > drivers/char/hw_random/omap-rng.c | 3 +-- > drivers/char/hw_random/powernv-rng.c | 10 +- > drivers/char/hw_random/st-rng.c| 4 +--- > drivers/char/hw_random/xgene-rng.c | 4 +--- > 9 files changed, 9 insertions(+), 36 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: nx: nx-842-powernv: Add of_node_put() before return
On Wed, Jul 24, 2019 at 01:24:33PM +0530, Nishka Dasgupta wrote: > Each iteration of for_each_compatible_node puts the previous node, but > in the case of a return from the middle of the loop, there is no put, > thus causing a memory leak. Add an of_node_put before the return. > Issue found with Coccinelle. > > Acked-by: Stewart Smith > Signed-off-by: Nishka Dasgupta > > --- > Changes in v2: > - Fixed commit message to match the loop in question. > > drivers/crypto/nx/nx-842-powernv.c | 1 + > 1 file changed, 1 insertion(+) 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 v5 0/4] *** SUBJECT HERE ***
On Mon, Jun 24, 2019 at 07:20:13AM +, Christophe Leroy wrote: > This series is the last set of fixes for the Talitos driver. > > We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and > SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS: > > [3.385197] bus: 'platform': really_probe: probing driver talitos with > device ff02.crypto > [3.450982] random: fast init done > [ 12.252548] alg: No test for authenc(hmac(md5),cbc(aes)) > (authenc-hmac-md5-cbc-aes-talitos-hsna) > [ 12.262226] alg: No test for authenc(hmac(md5),cbc(des3_ede)) > (authenc-hmac-md5-cbc-3des-talitos-hsna) > [ 43.310737] Bug in SEC1, padding ourself > [ 45.603318] random: crng init done > [ 54.612333] talitos ff02.crypto: fsl,sec1.2 algorithms registered in > /proc/crypto > [ 54.620232] driver: 'talitos': driver_bound: bound to device > 'ff02.crypto' > > [1.193721] bus: 'platform': really_probe: probing driver talitos with > device b003.crypto > [1.229197] random: fast init done > [2.714920] alg: No test for authenc(hmac(sha224),cbc(aes)) > (authenc-hmac-sha224-cbc-aes-talitos) > [2.724312] alg: No test for authenc(hmac(sha224),cbc(aes)) > (authenc-hmac-sha224-cbc-aes-talitos-hsna) > [4.482045] alg: No test for authenc(hmac(md5),cbc(aes)) > (authenc-hmac-md5-cbc-aes-talitos) > [4.490940] alg: No test for authenc(hmac(md5),cbc(aes)) > (authenc-hmac-md5-cbc-aes-talitos-hsna) > [4.500280] alg: No test for authenc(hmac(md5),cbc(des3_ede)) > (authenc-hmac-md5-cbc-3des-talitos) > [4.509727] alg: No test for authenc(hmac(md5),cbc(des3_ede)) > (authenc-hmac-md5-cbc-3des-talitos-hsna) > [6.631781] random: crng init done > [ 11.521795] talitos b003.crypto: fsl,sec2.2 algorithms registered in > /proc/crypto > [ 11.529803] driver: 'talitos': driver_bound: bound to device > 'b003.crypto' > > v2: dropped patch 1 which was irrelevant due to a rebase weirdness. Added Cc > to stable on the 2 first patches. > > v3: > - removed stable reference in patch 1 > - reworded patch 1 to include name of patch 2 for the dependency. > - mentionned this dependency in patch 2 as well. > - corrected the Fixes: sha1 in patch 4 > > v4: > - using scatterwalk_ffwd() instead of opencodying SG list forwarding. > - Added a patch to fix sg_copy_to_buffer() when sg->offset() is greater than > PAGE_SIZE, > otherwise sg_copy_to_buffer() fails when the list has been forwarded with > scatterwalk_ffwd(). > - taken the patch "crypto: talitos - eliminate unneeded 'done' functions at > build time" > out of the series because it is independent. > - added a helper to find the header field associated to a request in > flush_channe() > > v5: > - Replacing the while loop by a direct shift/mask operation, as suggested by > Herbert in patch 1. > > Christophe Leroy (4): > lib/scatterlist: Fix mapping iterator when sg->offset is greater than > PAGE_SIZE > crypto: talitos - move struct talitos_edesc into talitos.h > crypto: talitos - fix hash on SEC1. > crypto: talitos - drop icv_ool > > drivers/crypto/talitos.c | 102 > +++ > drivers/crypto/talitos.h | 28 + > lib/scatterlist.c| 9 +++-- > 3 files changed, 74 insertions(+), 65 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/NX: Set receive window credits to max number of CRBs in RxFIFO
On Tue, Jun 18, 2019 at 12:09:22PM -0700, Haren Myneni wrote:
>
> System gets checkstop if RxFIFO overruns with more requests than the
> maximum possible number of CRBs in FIFO at the same time. The max number
> of requests per window is controlled by window credits. So find max
> CRBs from FIFO size and set it to receive window credits.
>
> Fixes: b0d6c9bab5e4 ("crypto/nx: Add P9 NX support for 842 compression
> engine")
> CC: sta...@vger.kernel.org # v4.14+
> Signed-off-by:Haren Myneni
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
