Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

James Bottomley [off-list ref] writes:

On Wed, 2025-06-04 at 17:01 +0000, Eric Snowberg wrote:

quoted

quoted

On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov [off-list ref] 
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?

Well not rejected, just we always thought that people (like me) who
take control of their secure boot systems are a tiny minority who can
cope with being different.  I have to say the embedding of all the
variable manipulations in shim made it quite hard.  However you can use
the efitools KeyTool to get a graphical method for adding MoK keys even
in the absence of shim.

The question is, is there a growing use case for db users beyond the
exceptions who own their own keys on their laptop, in which case we
should reconsider this.

Yes, exactly; I may had missed some of the discussions but what I found
gave me the impression that the idea was never implemented just because
'db' was normally considered to be outside of user's control ("just a few
evil certs from MS"). This may still be true for bare metal but over the
last few years things have changed in a way that major cloud providers
started moving towards offering UEFI booted instances by default (or, in
some cases, UEFI-only instances). At least the three major hyperscalers
(AWS, GCP, Azure) offer fairly straightforward ways to customize 'db'
for SecureBoot; it is also possible to have a custom UEFI setup with
KVM/QEMU+OVMF based infrastructures. 

'certwrapper' offers _a_ solution which is great. It may, however, not
be very convenient to use when a user wants to re-use the same OS image
(e.g. provided by the distro vendor) for various different use-cases as
proper 'certwrapper' binary needs to be placed on the ESP (and thus
we'll end up with a bunch of images instead of one). 'db' is different
because it normally lives outside of the OS disk so it is possible to
register the exact same OS image with different properties (e.g. with
and without a custom cert which allows to load third party modules).

One additional consideration is the fact that we already trust 'db' for
dm-verity (since 6fce1f40e951) and kexec (since 278311e417be) and
especially the later gives someone who is able to control 'db' access to
CPL0; a 'db'-signed module (IMO) wouldn't change much.

-- 
Vitaly