linux-kernel - Re: [PATCH v4 08/33] crypto: rockchip: better handle cipher key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 11 Apr 2022 10:51:38 +0200
From:   LABBE Corentin <clabbe@...libre.com>
To:     John Keeping <john@...anate.com>
Cc:     heiko@...ech.de, herbert@...dor.apana.org.au, krzk+dt@...nel.org,
        robh+dt@...nel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v4 08/33] crypto: rockchip: better handle cipher key

Le Mon, Apr 04, 2022 at 12:31:11PM +0100, John Keeping a écrit :
> On Fri, Apr 01, 2022 at 08:17:39PM +0000, Corentin Labbe wrote:
> > The key should not be set in hardware too much in advance, this will
> > fail it 2 TFM with different keys generate alternative requests.
> > The key should be stored and used just before doing cipher operations.
> > 
> > Fixes: ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
> > Signed-off-by: Corentin Labbe <clabbe@...libre.com>
> > ---
> >  drivers/crypto/rockchip/rk3288_crypto.h          |  1 +
> >  drivers/crypto/rockchip/rk3288_crypto_skcipher.c | 10 +++++++---
> >  2 files changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/crypto/rockchip/rk3288_crypto.h b/drivers/crypto/rockchip/rk3288_crypto.h
> > index 8b1e15d8ddc6..826508e4a0c3 100644
> > --- a/drivers/crypto/rockchip/rk3288_crypto.h
> > +++ b/drivers/crypto/rockchip/rk3288_crypto.h
> > @@ -245,6 +245,7 @@ struct rk_ahash_rctx {
> >  struct rk_cipher_ctx {
> >  	struct rk_crypto_info		*dev;
> >  	unsigned int			keylen;
> > +	u32 key[AES_MAX_KEY_SIZE / 4];
> 
> Should this be u8?  It's only ever memcpy'd so the fact the registers
> are 32-bit is irrelevant.
> 
> (Also a very minor nit: this should probably be aligned in the same was
> as the above two variables.)

Yes, it could be u8 and I will fix the alignement.

Regards