Message-ID: <CALrw=nGkM9V12y7dB8y84UHKnroregUwiLBrtn5Xyf3k4pREsg@mail.gmail.com>
Date: Fri, 13 Jun 2025 16:21:35 +0100
From: Ignat Korchagin <ignat@...udflare.com>
To: David Howells <dhowells@...hat.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, Stephan Mueller <smueller@...onox.de>, 
	Simo Sorce <simo@...hat.com>, torvalds@...ux-foundation.org, 
	Paul Moore <paul@...l-moore.com>, Lukas Wunner <lukas@...ner.de>, Clemens Lang <cllang@...hat.com>, 
	David Bohannon <dbohanno@...hat.com>, Roberto Sassu <roberto.sassu@...wei.com>, keyrings@...r.kernel.org, 
	linux-crypto@...r.kernel.org, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: Module signing and post-quantum crypto public key algorithms

Hi David,

On Fri, Jun 13, 2025 at 3:54 PM David Howells <dhowells@...hat.com> wrote:
>
> Hi,
>
> So we need to do something about the impending quantum-related obsolescence of
> the RSA signatures that we use for module signing, kexec, BPF signing, IMA and
> a bunch of other things.

Is it that impending? At least for now it seems people are more
concerned about quantum-safe TLS, so their communications cannot be
decrypted later. But breaking signatures of open source modules
probably only makes sense when there is an actual capability to break
RSA (or ECDSA)

> From my point of view, the simplest way would be to implement key verification
> in the kernel for one (or more) of the available post-quantum algorithms (of
> which there are at least three), driving this with appropriate changes to the
> X.509 certificate to indicate that's what we want to use.
>
> The good news is that Stephan Mueller has an implemementation that includes
> kernel bits that we can use, or, at least, adapt:
>
>         https://github.com/smuellerDD/leancrypto/
>
> Note that we only need the signature verification bits.  One question, though:
> he's done it as a standalone "leancrypto" module, not integrated into crypto/,
> but should it be integrated into crypto/ or is the standalone fine?
>
> The not so good news, as I understand it, though, is that the X.509 bits are
> not yet standardised.

Does it matter from a kernel perspective? As far as I remember we just
attach the "plain" signature to binary. Or is it about provisioning
the key through the keystore?

>
> However!  Not everyone agrees with this.  An alternative proposal would rather
> get the signature verification code out of the kernel entirely.  Simo Sorce's
> proposal, for example, AIUI, is to compile all the hashes we need into the
> kernel at build time, possibly with a hashed hash list to be loaded later to
> reduce the amount of uncompressible code in the kernel.  If signatures are
> needed at all, then this should be offloaded to a userspace program (which
> would also have to be hashed and marked unptraceable and I think unswappable)
> to do the checking.

Can indeed work for modules, but with our limited deployment of IMA in
production with many services even with the current approach we get
some complains:
  * verification takes too long for some binaries (which were not
stripped for example)
  * just hashing the binaries over and over burns some CPU and
actually burns only 1 CPU at a time (stalling it)

We need to consider cases, for example, when a python script calls
some binaries via system(3) or similar in a tight loop. Yes, with IMA
we would verify only once, but still there are cases, when software
updates happen frequently or config management "templates" the
binaries, so they change all the time.

> I don't think we can dispense with signature checking entirely, though: we
> need it for third party module loading, quick single-module driver updates and
> all the non-module checking stuff.  If it were to be done in userspace, this
> might entail an upcall for each signature we want to check - either that, or
> the kernel has to run a server process that it can delegate checking to.

Agreed - we should have an in-kernel option

> It's also been suggested that PQ algorithms are really slow.  For kernel
> modules that might not matter too much as we may well not load more than 200
> or so during boot - but there are other users that may get used more
> frequently (IMA, for example).

Yep, mentioned above.

>
> Now, there's also a possible hybrid approach, if I understand Roberto Sassu's
> proposal correctly, whereby it caches bundles of hashes obtained from, say,
> the hashes included in an RPM.  These bundles of hashes can be checked by
> signature generated by the package signing process.  This would reduce the PQ
> overhead to checking a bundle and would also make IMA's measuring easier as
> the hashes can be added in the right order, rather than being dependent on the
> order that the binaries are used.

This makes it somewhat similar to UEFI secure boot trusted signature
DB, where one can have either a trusted public key to verify the
signature or a direct allowlist of hashes

> David
>

Ignat

Powered by blists - more mailing lists