linux-kernel - Re: [PATCH v12 06/10] crypto: Add supplementary info param to asymmetric key signature verification

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]

Message-ID: <20260121000607.GA12110@quark>
Date: Tue, 20 Jan 2026 16:06:07 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Lukas Wunner <lukas@...ner.de>, Ignat Korchagin <ignat@...udflare.com>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Petr Pavlu <petr.pavlu@...e.com>,
	Daniel Gomez <da.gomez@...nel.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	"Jason A . Donenfeld" <Jason@...c4.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Stephan Mueller <smueller@...onox.de>, linux-crypto@...r.kernel.org,
	keyrings@...r.kernel.org, linux-modules@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v12 06/10] crypto: Add supplementary info param to
 asymmetric key signature verification

On Tue, Jan 20, 2026 at 11:39:46PM +0000, David Howells wrote:
> Eric Biggers <ebiggers@...nel.org> wrote:
> 
> > As I'm sure you're aware, C has native support for function parameters.
> 
> And we have a syscall interface to honour that takes a parameter string *for
> this very purpose*.  It just wasn't threaded into the akcipher API.

This seems to be more of a bug than a feature, though.  It seems the
actual goals of this patchset are to add ML-DSA and RSASSA-PSS support
to kernel module signing.  But because of how the code is organized, as
a side effect it ended up extending the KEYCTL_PKEY_* UAPIs as well.
Linux's UAPI stability guarantee holds for these UAPIs; anything that we
add to them, including these ad-hoc and undocumented parameter strings,
will likely have to be supported forever.

Unless these keyctl UAPI extensions are well-justified and come with
documentation and tests, we should just hold off on them for now.
What's the hurry?

BTW, we got hit by this when there was an attempt to remove SHA-1
support from module signing.  Due to the design defect where the signing
is also exposed through KEYCTL_PKEY_*, it caused a UAPI regression as
well and had to be reverted.

- Eric