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