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

[James Bottomley]

On Wed, 2025-06-04 at 17:01 +0000, Eric Snowberg wrote:
> > On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets at redhat.com> 
> > 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.

Regards,

James