mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Daniel Gomez <da.gomez@samsung.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Eric Snowberg <eric.snowberg@oracle.com>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Peter Jones <pjones@redhat.com>,
	Robert Holmes <robeholmes@gmail.com>,
	Jeremy Cline <jcline@redhat.com>, Coiby Xu <coxu@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification
Date: Mon,  2 Jun 2025 15:25:34 +0200	[thread overview]
Message-ID: <20250602132535.897944-1-vkuznets@redhat.com> (raw)

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.

The suggested approach is not to change the default, but to introduce a
Kconfig variable (CONFIG_MODULE_SIG_PLATFORM) doing the job. Note, the 
kernel already trusts '.platform' for kexec (see commit 278311e417be 
("kexec, KEYS: Make use of platform keyring for signature verify"))
and dm-verity (see commit 6fce1f40e951 ("dm verity: add support for
signature verification with platform keyring")) so maybe changing the
default or introducing a generic '.plarform is fully trusted' option
would actually be better.

Vitaly Kuznetsov (1):
  module: Make use of platform keyring for module signature verify

 Documentation/admin-guide/module-signing.rst |  6 ++++++
 kernel/module/Kconfig                        | 11 +++++++++++
 kernel/module/signing.c                      |  9 ++++++++-
 security/integrity/Kconfig                   |  2 +-
 4 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.49.0


             reply	other threads:[~2025-06-02 13:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02 13:25 Vitaly Kuznetsov [this message]
2025-06-02 13:25 ` [PATCH RFC 1/1] module: Make use of platform keyring for module signature verify Vitaly Kuznetsov
2025-06-02 18:34   ` James Bottomley
2025-06-03  8:52     ` Vitaly Kuznetsov
2025-06-03 13:03       ` James Bottomley
2025-06-04  7:47         ` Vitaly Kuznetsov
2025-06-05  8:34         ` Coiby Xu
2025-06-05 12:05           ` James Bottomley
2025-06-08 11:14             ` Coiby Xu
2025-06-04 17:01 ` [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification Eric Snowberg
2025-06-04 17:34   ` James Bottomley
2025-06-05  7:54     ` Vitaly Kuznetsov
2025-06-05 12:22       ` James Bottomley
2025-06-05 13:43         ` Vitaly Kuznetsov
2025-06-05 15:49           ` James Bottomley
2025-06-09  8:58             ` Vitaly Kuznetsov
2025-06-05 13:35       ` Eric Snowberg
2025-06-05 14:56         ` Vitaly Kuznetsov
2025-06-05 14:35 ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250602132535.897944-1-vkuznets@redhat.com \
    --to=vkuznets@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=corbet@lwn.net \
    --cc=coxu@redhat.com \
    --cc=da.gomez@samsung.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.snowberg@oracle.com \
    --cc=jcline@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=kraxel@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=petr.pavlu@suse.com \
    --cc=pjones@redhat.com \
    --cc=robeholmes@gmail.com \
    --cc=roberto.sassu@huawei.com \
    --cc=samitolvanen@google.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®