| Message ID | qvgp2il2co4iyxkzxvcs4p2bpyilqsbfgcprtpfrsajwae2etc@3z2s2o52i3xg (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KEYS: Make use of platform keyring for module signature verification | expand |
On Fri, Mar 31, 2023 at 04:30:21PM +0200, Ahelenia Ziemiańska wrote: > This allows a cert in DB to be used to sign modules, > in addition to certs in the MoK and built-in keyrings. > > This key policy matches what's used for kexec. > > Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Before I nose dive, the commit log should explain why this patch never was sent upstream, if it was, why it was rejected. What makes it good now? Who is using it? What are other distributions doing about it? Luis
On Fri, Mar 31, 2023 at 01:01:43PM -0700, Luis Chamberlain wrote: > On Fri, Mar 31, 2023 at 04:30:21PM +0200, Ahelenia Ziemiańska wrote: > > This allows a cert in DB to be used to sign modules, > > in addition to certs in the MoK and built-in keyrings. > > > > This key policy matches what's used for kexec. > Before I nose dive, the commit log should explain why this patch never > was sent upstream, if it was, why it was rejected. How would I know that? Searching around on the list, I found an equivalent 2022-02-15 patch: https://lore.kernel.org/linux-kernel/840433bc93a58d6dfc4d96c34c0c3b158a0e669d.1644953683.git.msuchanek@suse.de/t/#u and there's even a reply from you in there. The discussion appears to boil down to ".platform is restricted to kexec", "there are common setups in which it'd make much more sense to allow this, and also it's prety equivalent security-policy-wise", (this repeats). MoK/shim is also mentioned, for some reason, even though that solves a different problem. > What makes it good now? Debian and Fedora are using it, and it's what users expect to work. > Who is using it? Debian (since 5.3.9-1, #935945) and Fedora (since the time of that bug at the very least, as Debian imported from there, so 2019-11-09). > What are other distributions doing about it? What does that mean, and also how would I know that? Best,
diff --git a/kernel/module/signing.c b/kernel/module/signing.c index a2ff4242e623..71d6248cf9ec 100644 --- a/kernel/module/signing.c +++ b/kernel/module/signing.c @@ -61,10 +61,16 @@ int mod_verify_sig(const void *mod, struct load_info *info) modlen -= sig_len + sizeof(ms); info->len = modlen; - return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, - VERIFY_USE_SECONDARY_KEYRING, - VERIFYING_MODULE_SIGNATURE, - NULL, NULL); + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, + VERIFY_USE_SECONDARY_KEYRING, + VERIFYING_MODULE_SIGNATURE, + NULL, NULL); + if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) + ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len, + VERIFY_USE_PLATFORM_KEYRING, + VERIFYING_MODULE_SIGNATURE, + NULL, NULL); + return ret; } int module_sig_check(struct load_info *info, int flags)
This allows a cert in DB to be used to sign modules, in addition to certs in the MoK and built-in keyrings. This key policy matches what's used for kexec. Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> --- Notes: Debian has carried an equivalent patch since 5.3.9-1: https://bugs.debian.org/935945 https://bugs.debian.org/1030200 in https://salsa.debian.org/kernel-team/linux/-/commit/0e65c8f3e316d6f0fc30f091dd47dba2ac616529 and it appears the true origin is some version of https://gitlab.com/cki-project/kernel-ark/-/commit/b697ff5e26974fee8fcd31a1e221e9dd41515efc kernel/module/signing.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)