Re: [PATCH] crypto: padlock-aes - convert to skcipher API

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Oct 13, 2019 at 11:20:51PM +0000, Jamie Heilman wrote:
> Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Convert the VIA PadLock implementations of AES-ECB and AES-CBC from the
> > deprecated "blkcipher" API to the "skcipher" API.  This is needed in
> > order for the blkcipher API to be removed.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> > 
> > This is compile-tested only, as I don't have this hardware.
> > If anyone has this hardware, please test it with
> > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y.
> 
> Well I gave it a spin on my Esther system against 5.3.6 but results
> were somewhat obscured by the fact I seem to have other problems with
> modern kernels (I'd been running Greg's 4.19 series on this system
> which doesn't have the extra tests you wanted) on this hardware to the
> tune of (from an unpatched 5.3.6):
> 
>  Loading compiled-in X.509 certificates
>  ------------[ cut here ]------------
>  WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:539 pkcs1pad_verify+0x2d/0xf4
>  Modules linked in:
>  CPU: 0 PID: 1 Comm: swapper Tainted: G                T 5.3.6 #2
>  Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014  06/01/2009
>  EIP: pkcs1pad_verify+0x2d/0xf4
>  Code: 57 56 53 89 c3 83 7b 1c 00 74 0e 68 c8 7a 46 c1 e8 48 43 ec ff 0f 0b eb 13 8b 53 24 85 d2 75 17 68 c8 7a 46 c1 e8 33 43 ec ff <0f> 0b 59 b8 ea ff ff ff e9 b2 00 00 00 8b 73 10 b8 ea ff ff ff 8b
>  EAX: 00000024 EBX: f124a3c0 ECX: 00000100 EDX: c14fab54
>  ESI: 00000000 EDI: f124a3c0 EBP: f106bd58 ESP: f106bd48
>  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 EFLAGS: 00010246
>  CR0: 80050033 CR2: 00000000 CR3: 0158c000 CR4: 000006b0
>  Call Trace:
>   public_key_verify_signature+0x1ff/0x26b
>   x509_check_for_self_signed+0x9f/0xb8
>   x509_cert_parse+0x149/0x179
>   x509_key_preparse+0x1a/0x16d
>   ? __down_read+0x26/0x29
>   asymmetric_key_preparse+0x35/0x56
>   key_create_or_update+0x121/0x330
>   load_system_certificate_list+0x77/0xc5
>   ? system_trusted_keyring_init+0x4f/0x4f
>   do_one_initcall+0x7b/0x158
>   kernel_init_freeable+0xd7/0x156
>   ? rest_init+0x6d/0x6d
>   kernel_init+0x8/0xd0
>   ret_from_fork+0x33/0x40
>  ---[ end trace 1ec5d41c10bd49a3 ]---
>  Problem loading in-kernel X.509 certificate (-22)
> 
> That said, I get this issue with or without your patch, so I assume
> it's unrelated, and probably something with c7381b01287240ab that
> introduced that WARN_ON.  Anyways, I'll have to run a real bisection
> on that when I have the time.

Yes, that's something unrelated.  It looks to be a bug caused by recent changes
to the asymmetric keys subsystem, triggered by not having some hash algorithm
built into the kernel (probably SHA-256).  I recommend starting a new thread for
that with:

	David Howells <dhowells@redhat.com>
	Vitaly Chikunov <vt@altlinux.org>
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
	keyrings@vger.kernel.org
	linux-crypto@vger.kernel.org

> 
> I built a patched 5.3.6 with none of the crypto bits modularized and
> you can find that dmesg and config at:
> 
> http://audible.transient.net/~jamie/k/skcipher.config-5.3.6
> http://audible.transient.net/~jamie/k/skcipher.dmesg
> 

Great, I don't see any test failures in the log.  Just to double check, you had
applied both Ard's patch and this one, right?:

	crypto: geode-aes - switch to skcipher for cbc(aes) fallback
	crypto: geode-aes - convert to skcipher API and make thread-safe

- Eric