linux-kernel - Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0FD18D05-6114-4A25-BD77-C32C1D706CC3@oracle.com>
Date: Wed, 4 Jun 2025 17:01:58 +0000
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
CC: "linux-security-module@...r.kernel.org"
	<linux-security-module@...r.kernel.org>,
        "linux-integrity@...r.kernel.org"
	<linux-integrity@...r.kernel.org>,
        "linux-modules@...r.kernel.org"
	<linux-modules@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>,
        "keyrings@...r.kernel.org"
	<keyrings@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        David
 Woodhouse <dwmw2@...radead.org>,
        Jonathan Corbet <corbet@....net>,
        Luis
 Chamberlain <mcgrof@...nel.org>,
        Petr Pavlu <petr.pavlu@...e.com>,
        Sami
 Tolvanen <samitolvanen@...gle.com>,
        Daniel Gomez <da.gomez@...sung.com>, Mimi
 Zohar <zohar@...ux.ibm.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Dmitry
 Kasatkin <dmitry.kasatkin@...il.com>,
        Paul Moore <paul@...l-moore.com>, James
 Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>, Peter Jones
	<pjones@...hat.com>,
        Robert Holmes <robeholmes@...il.com>,
        Jeremy Cline
	<jcline@...hat.com>, Coiby Xu <coxu@...hat.com>,
        James Bottomley
	<James.Bottomley@...senPartnership.com>,
        Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for
 signatures verification



> On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
> 
> UEFI SecureBoot 'db' keys are currently not trusted for modules signatures
> verification. RedHat based downstream distros (RHEL, Fedora, ...) carry a
> patch changing that for many years (since 2019 at least). This RFC is an
> attempt to upstream it as the functionality seems to be generally useful.
> 
> Previously, pre-boot keys (SecureBoot 'db', MOK) were not trusted within
> kernel at all. Things have changed since '.machine' keyring got introduced
> making MOK keys optionally trusted. Before that, there was a discussion to
> make .platform trusted by default:
> https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
> which didn't go very far because the assumption was that this is only useful
> when the user has control over 'db'. I believe there's a fairly common
> use-case where this is true.
> 
> The use-case: virtualized and cloud infrastructure generally provide an
> ability to customize SecureBoot variables, in particular, it is possible
> to bring your own SecureBoot 'db'. This may come handy when a user wants to
> load a third party kernel module (self built or provided by a third party
> vendor) while still using a distro provided kernel. Generally, distro
> provided kernels sign modules with an ephemeral key and discard the private
> part during the build. While MOK can sometimes be used to sign something
> out-of-tree, it is a tedious process requiring either a manual intervention
> with shim or a 'certmule' 
> (see https://blogs.oracle.com/linux/post/the-machine-keyring). In contrast,
> the beauty of using SecureBoot 'db' in this scenario is that for public
> clouds and virtualized infrastructure it is normally a property of the OS
> image (or the whole infrastructure/host) and not an individual instance;
> this means that all instances created from the same template will have 'db'
> keys in '.platform' by default.

Hasn’t this approach been rejected multiple times in the past?

The addition of the certmule (now called certwrapper) was precisely added 
for the use case you’ve described. If they control the ‘db’, they can create a 
certwrapper containing their key.

With the machine keyring, the end-user is in control. If they don’t want to 
trust MOK keys in their kernel, they have the ability to disable it. This will 
prevent shim from creating the MokListTrustedRT var and prevent Linux 
from using MOK keys to validate kernel modules.