[PATCH 0/2] Add support for ECDSA-signed kernel modules

Jarkko Sakkinen jarkko at kernel.org
Wed Apr 7 20:15:38 UTC 2021


On Wed, Apr 07, 2021 at 01:53:24PM -0400, Stefan Berger wrote:
> 
> On 4/7/21 12:10 PM, Mimi Zohar wrote:
> > On Wed, 2021-04-07 at 18:53 +0300, Jarkko Sakkinen wrote:
> > > On Tue, Apr 06, 2021 at 02:53:38PM -0400, Stefan Berger wrote:
> > > > This series adds support for ECDSA-signed kernel modules.
> > > > 
> > > > The first patch in this series attempts to address the issue where a
> > > > developer created an ECDSA key for signing modules and then falls back
> > > > to compiling an older version of the kernel that does not support
> > > > ECDSA keys. In this case this patch would delete that ECDSA key if it is
> > > > in certs/signing_key.pem and trigger the creation of an RSA key. However,
> > > > for this to work this patch would have to be applied to previous versions
> > > > of the kernel but would also only work for the developer if he/she used a
> > > > stable version of the kernel to which this patch was applied. So whether
> > > > this patch actually achieves the wanted effect is not always guaranteed.
> > > Just wondering why the key needs to be removed in the fallback.
> Because if you signed an older kernel's modules with the ECDSA key it won't
> be able to load the modules...
> > The main concern is with bisecting the kernel.  Either elliptic curve
> > support or the first patch needs to be backported.  This patch will
> > cause the kernel module signing key to be regenerated.
> 
> 
> This assumes of course that one will bisect via the stable kernels where
> this 1st patch has been applied. Not sure whether that's what people will
> do.

In any case, sounds non-trivial issue enough ought to be documented in the
commit message.

/Jarkko



More information about the Linux-security-module-archive mailing list