[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Feb 2021 16:13:46 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Daniele Alessandrelli <daniele.alessandrelli@...ux.intel.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, Meng Yu <yumeng18@...wei.com>,
"David S. Miller" <davem@...emloft.net>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Zaibo Xu <xuzaibo@...wei.com>, wangzhou1@...ilicon.com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mark Gross <mgross@...ux.intel.com>,
"Khurana, Prabhjot" <prabhjot.khurana@...el.com>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Daniele Alessandrelli <daniele.alessandrelli@...el.com>
Subject: Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
On Mon, Feb 01, 2021 at 05:09:41PM +0000, Daniele Alessandrelli wrote:
> What's the downside of letting device drivers enable all the curves
> supported by the HW (with the exception of obsolete curves /
> algorithms), even if there is (currently) no user of such curves in the
> kernel? Code size and maintainability?
The issue is that we always require a software implementation for
any given hardware algorithm. As otherwise kernel users cannot
rely on the algorithm to work.
Of course we don't want to add every single algorithm out there
to the kernel so that's why require there to be an actual in-kernel
user before adding a given algorithm.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists