linux-kernel - RE: [PATCH 1/7] crypto: tegra: Use separate buffer for setkey

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH7PR12MB8178F6A37DE6CD41850529BBC00A2@PH7PR12MB8178.namprd12.prod.outlook.com>
Date: Tue, 31 Dec 2024 04:25:06 +0000
From: Akhil R <akhilrajeev@...dia.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: "davem@...emloft.net" <davem@...emloft.net>, "thierry.reding@...il.com"
	<thierry.reding@...il.com>, Jon Hunter <jonathanh@...dia.com>,
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/7] crypto: tegra: Use separate buffer for setkey

> On Tue, Dec 17, 2024 at 09:42:01PM +0530, Akhil R wrote:
> > The buffer which sends the commands to host1x was shared for all tasks
> > in the engine. This causes a problem with the setkey() function as it
> > gets called asynchronous to the crypto engine queue. Modifying the
> > same cmdbuf in setkey() will corrupt the ongoing host1x task and in
> > turn break the encryption/decryption operation. Hence use a separate
> > cmdbuf for setkey().
> >
> > Fixes:  0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine
> > driver")
> > Signed-off-by: Akhil R <akhilrajeev@...dia.com>
> > ---
> >  drivers/crypto/tegra/tegra-se-aes.c  | 16 ++++++++--------
> > drivers/crypto/tegra/tegra-se-hash.c | 13 +++++++------
> > drivers/crypto/tegra/tegra-se-key.c  | 10 ++++++++--
> > drivers/crypto/tegra/tegra-se-main.c | 16 ++++++++++++----
> >  drivers/crypto/tegra/tegra-se.h      |  3 ++-
> >  5 files changed, 37 insertions(+), 21 deletions(-)
> 
> So there is a maximum of 15 key slots? In that case you should not be allocating
> them in setkey because there can be a lot more than
> 15 tfm's in the system.
> 
> Since the limit is so low they should only be allocated during an
> encryption/decryption operation.

Yes. That's right. The hardware has only 15 keyslots.

I am working on a patch which will reserve few keyslots and use them during
encryption/decription operation in case the remaining keyslots get full. Means,
the setkey will try to get a keyslot, if it fails it will store the key in a variable. Then
during the encryption/decryption, it will use one of the reserved keyslot for the
operation.

This will allow users to have the capability of hardware protected keys and faster
operations if there are limited number of tfms. It also does not halt the operation
when there are more tfms.

Does it sound good, or do you think it will make the code overly complicated?

Regards,
Akhil