[Cc'ing Eric Snowberg]
Hi Michal,
On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> adds support for use of platform keyring in kexec verification but
> support for modules is missing.
>
> Add support for verification of modules with keys from platform keyring
> as well.
Permission for loading the pre-OS keys onto the "platform" keyring and
using them is limited to verifying the kexec kernel image, nothing
else.
FYI, Eric Snowberg's initial patch set titled "[PATCH v10 0/8] Enroll
kernel keys thru MOK" is queued in Jarkko's git repo to be usptreamed.
A subsequent patch set is expected.
--
thanks,
Mimi
[1] Message-Id: <[email protected]>
Hello,
On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> [Cc'ing Eric Snowberg]
>
> Hi Michal,
>
> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > adds support for use of platform keyring in kexec verification but
> > support for modules is missing.
> >
> > Add support for verification of modules with keys from platform keyring
> > as well.
>
> Permission for loading the pre-OS keys onto the "platform" keyring and
> using them is limited to verifying the kexec kernel image, nothing
> else.
Why is the platform keyring limited to kexec, and nothing else?
It should either be used for everything or for nothing. You have the
option to compile it in and then it should be used, and the option to
not compile it in and then it cannot be used.
There are two basic use cases:
(1) there is a vendor key which is very hard to use so you sign
something small and simple like shim with the vendor key, and sign your
kernel and modules with your own key that's typically enrolled with shim
MOK, and built into the kernel.
(2) you import your key into the firmware, and possibly disable the
vendor key. You can load the kernel directly without shim, and then your
signing key is typically in the platform keyring and built into the
kernel.
In neither case do I see any reason to use some keyrings for kexec and
other keyrings for modules.
Thanks
Michal
On Tue, 2022-02-15 at 21:47 +0100, Michal Such?nek wrote:
> Hello,
>
> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > [Cc'ing Eric Snowberg]
> >
> > Hi Michal,
> >
> > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > adds support for use of platform keyring in kexec verification but
> > > support for modules is missing.
> > >
> > > Add support for verification of modules with keys from platform keyring
> > > as well.
> >
> > Permission for loading the pre-OS keys onto the "platform" keyring and
> > using them is limited to verifying the kexec kernel image, nothing
> > else.
>
> Why is the platform keyring limited to kexec, and nothing else?
>
> It should either be used for everything or for nothing. You have the
> option to compile it in and then it should be used, and the option to
> not compile it in and then it cannot be used.
>
> There are two basic use cases:
>
> (1) there is a vendor key which is very hard to use so you sign
> something small and simple like shim with the vendor key, and sign your
> kernel and modules with your own key that's typically enrolled with shim
> MOK, and built into the kernel.
>
> (2) you import your key into the firmware, and possibly disable the
> vendor key. You can load the kernel directly without shim, and then your
> signing key is typically in the platform keyring and built into the
> kernel.
>
> In neither case do I see any reason to use some keyrings for kexec and
> other keyrings for modules.
When building your own kernel there isn't a problem. Additional keys
may be built into the kernel image, which are loaded onto the
".builtin_trusted_keys" keyring, and may be stored in MOK. Normally
different keys are used for signing the kernel image and kernel
modules. Kernel modules can be signed by the build time ephemeral
kernel module signing key, which is built into the kernel and
automatically loaded onto the ".builtin_trusted_keys" keyring.
Similarly distros build the kernel module signing key into the kernel,
which is built into the kernel and loaded onto the
".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the
".platform" keyring, kexec may verify the distro or other signed
kernel images.
--
thanks,
Mimi
On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> On Tue, 2022-02-15 at 21:47 +0100, Michal Such?nek wrote:
> > Hello,
> >
> > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > [Cc'ing Eric Snowberg]
> > >
> > > Hi Michal,
> > >
> > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > adds support for use of platform keyring in kexec verification but
> > > > support for modules is missing.
> > > >
> > > > Add support for verification of modules with keys from platform keyring
> > > > as well.
> > >
> > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > using them is limited to verifying the kexec kernel image, nothing
> > > else.
> >
> > Why is the platform keyring limited to kexec, and nothing else?
> >
> > It should either be used for everything or for nothing. You have the
> > option to compile it in and then it should be used, and the option to
> > not compile it in and then it cannot be used.
> >
> > There are two basic use cases:
> >
> > (1) there is a vendor key which is very hard to use so you sign
> > something small and simple like shim with the vendor key, and sign your
> > kernel and modules with your own key that's typically enrolled with shim
> > MOK, and built into the kernel.
> >
> > (2) you import your key into the firmware, and possibly disable the
> > vendor key. You can load the kernel directly without shim, and then your
> > signing key is typically in the platform keyring and built into the
> > kernel.
> >
> > In neither case do I see any reason to use some keyrings for kexec and
> > other keyrings for modules.
>
> When building your own kernel there isn't a problem. Additional keys
> may be built into the kernel image, which are loaded onto the
> ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally
> different keys are used for signing the kernel image and kernel
That's actually not normal.
> modules. Kernel modules can be signed by the build time ephemeral
> kernel module signing key, which is built into the kernel and
> automatically loaded onto the ".builtin_trusted_keys" keyring.
Right, there is this advice to use ephemeral key to sign modules.
I don't think that's a sound advice in general. It covers only the
special case when you build the kernel once, only rebuild the whole
kernel and never just one module, don't use any 3rd party module, don't
bother signing firmware (I am not sure that is supported right now but
if you are into integrity and stuff you can see that it makes sense to
sign it, too).
And you need to manage the key you use for the kernel signing, anyway.
Sure, you could use the same ephemeral key as for the modules, enroll
it, and shred it but then it is NOT a key different from the one you use
for modules.
Or you could maintain a long-lived key for the kernel, but if you do I
do NOT see any reason to not use it also for modules, in-tree and
out-of-tree.
> Similarly distros build the kernel module signing key into the kernel,
> which is built into the kernel and loaded onto the
> ".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the
> ".platform" keyring, kexec may verify the distro or other signed
> kernel images.
Which are signed by the same key as the modules so there is no reason to
load the platform key at all. I don't think loading shim with kexec is
supported.
Thanks
Michal
On Wed, 2022-02-16 at 11:56 +0100, Michal Such?nek wrote:
> On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > On Tue, 2022-02-15 at 21:47 +0100, Michal Such?nek wrote:
> > > Hello,
> > >
> > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > [Cc'ing Eric Snowberg]
> > > >
> > > > Hi Michal,
> > > >
> > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > adds support for use of platform keyring in kexec verification but
> > > > > support for modules is missing.
> > > > >
> > > > > Add support for verification of modules with keys from platform keyring
> > > > > as well.
> > > >
> > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > using them is limited to verifying the kexec kernel image, nothing
> > > > else.
> > >
> > > Why is the platform keyring limited to kexec, and nothing else?
> > >
> > > It should either be used for everything or for nothing. You have the
> > > option to compile it in and then it should be used, and the option to
> > > not compile it in and then it cannot be used.
> > >
> > > There are two basic use cases:
> > >
> > > (1) there is a vendor key which is very hard to use so you sign
> > > something small and simple like shim with the vendor key, and sign your
> > > kernel and modules with your own key that's typically enrolled with shim
> > > MOK, and built into the kernel.
> > >
> > > (2) you import your key into the firmware, and possibly disable the
> > > vendor key. You can load the kernel directly without shim, and then your
> > > signing key is typically in the platform keyring and built into the
> > > kernel.
> > >
> > > In neither case do I see any reason to use some keyrings for kexec and
> > > other keyrings for modules.
> >
> > When building your own kernel there isn't a problem. Additional keys
> > may be built into the kernel image, which are loaded onto the
> > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally
> > different keys are used for signing the kernel image and kernel
>
> That's actually not normal.
>
> > modules. Kernel modules can be signed by the build time ephemeral
> > kernel module signing key, which is built into the kernel and
> > automatically loaded onto the ".builtin_trusted_keys" keyring.
>
> Right, there is this advice to use ephemeral key to sign modules.
>
> I don't think that's a sound advice in general. It covers only the
> special case when you build the kernel once, only rebuild the whole
> kernel and never just one module, don't use any 3rd party module, don't
> bother signing firmware (I am not sure that is supported right now but
> if you are into integrity and stuff you can see that it makes sense to
> sign it, too).
>
> And you need to manage the key you use for the kernel signing, anyway.
> Sure, you could use the same ephemeral key as for the modules, enroll
> it, and shred it but then it is NOT a key different from the one you use
> for modules.
>
> Or you could maintain a long-lived key for the kernel, but if you do I
> do NOT see any reason to not use it also for modules, in-tree and
> out-of-tree.
If signing ALL kernel modules, in-tree and out-of-tree, with the same
key as the kernel image, is your real intention, then by all means
write a complete patch description with the motivation for why kernel
module signatures need to be verified against this one pre-OS key
stored only in the platform keyring. Such a major change like this
shouldn't be buried here.
Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys
thru MOK patch set" patch set [1], as previously mentioned, which is
queued to be upstreamed by Jarkko. It loads MOK keys onto the
'.machine' keyring, which is linked to the '.secondary_trusted_keys"
keyring. A subsequent patch set will enable IMA support.
[1]
https://lore.kernel.org/lkml/[email protected]/
--
thanks,
Mimi
On Wed, Feb 16, 2022 at 11:56:45AM +0100, Michal Such?nek wrote:
> On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > On Tue, 2022-02-15 at 21:47 +0100, Michal Such?nek wrote:
> > > Hello,
> > >
> > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > [Cc'ing Eric Snowberg]
> > > >
> > > > Hi Michal,
> > > >
> > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > adds support for use of platform keyring in kexec verification but
> > > > > support for modules is missing.
> > > > >
> > > > > Add support for verification of modules with keys from platform keyring
> > > > > as well.
> > > >
> > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > using them is limited to verifying the kexec kernel image, nothing
> > > > else.
> > >
> > > Why is the platform keyring limited to kexec, and nothing else?
> > >
> > > It should either be used for everything or for nothing. You have the
> > > option to compile it in and then it should be used, and the option to
> > > not compile it in and then it cannot be used.
> > >
> > > There are two basic use cases:
> > >
> > > (1) there is a vendor key which is very hard to use so you sign
> > > something small and simple like shim with the vendor key, and sign your
> > > kernel and modules with your own key that's typically enrolled with shim
> > > MOK, and built into the kernel.
> > >
> > > (2) you import your key into the firmware, and possibly disable the
> > > vendor key. You can load the kernel directly without shim, and then your
> > > signing key is typically in the platform keyring and built into the
> > > kernel.
> > >
> > > In neither case do I see any reason to use some keyrings for kexec and
> > > other keyrings for modules.
> >
> > When building your own kernel there isn't a problem. Additional keys
> > may be built into the kernel image, which are loaded onto the
> > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally
> > different keys are used for signing the kernel image and kernel
>
> That's actually not normal.
>
> > modules. Kernel modules can be signed by the build time ephemeral
> > kernel module signing key, which is built into the kernel and
> > automatically loaded onto the ".builtin_trusted_keys" keyring.
>
> Right, there is this advice to use ephemeral key to sign modules.
>
> I don't think that's a sound advice in general. It covers only the
> special case when you build the kernel once, only rebuild the whole
> kernel and never just one module, don't use any 3rd party module, don't
> bother signing firmware (I am not sure that is supported right now but
> if you are into integrity and stuff you can see that it makes sense to
> sign it, too).
And don't forget signing ramdisk which you typically don't build only
once at kernel build time.
>
> And you need to manage the key you use for the kernel signing, anyway.
> Sure, you could use the same ephemeral key as for the modules, enroll
> it, and shred it but then it is NOT a key different from the one you use
> for modules.
>
> Or you could maintain a long-lived key for the kernel, but if you do I
> do NOT see any reason to not use it also for modules, in-tree and
> out-of-tree.
>
> > Similarly distros build the kernel module signing key into the kernel,
> > which is built into the kernel and loaded onto the
> > ".builtin_trusted_keys" keyring. By loading the pre-OS keys onto the
> > ".platform" keyring, kexec may verify the distro or other signed
> > kernel images.
>
> Which are signed by the same key as the modules so there is no reason to
> load the platform key at all. I don't think loading shim with kexec is
> supported.
>
> Thanks
>
> Michal
On Wed, Feb 16, 2022 at 06:58:51AM -0500, Mimi Zohar wrote:
> On Wed, 2022-02-16 at 11:56 +0100, Michal Such?nek wrote:
> > On Tue, Feb 15, 2022 at 05:12:32PM -0500, Mimi Zohar wrote:
> > > On Tue, 2022-02-15 at 21:47 +0100, Michal Such?nek wrote:
> > > > Hello,
> > > >
> > > > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > > > [Cc'ing Eric Snowberg]
> > > > >
> > > > > Hi Michal,
> > > > >
> > > > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > > > adds support for use of platform keyring in kexec verification but
> > > > > > support for modules is missing.
> > > > > >
> > > > > > Add support for verification of modules with keys from platform keyring
> > > > > > as well.
> > > > >
> > > > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > > > using them is limited to verifying the kexec kernel image, nothing
> > > > > else.
> > > >
> > > > Why is the platform keyring limited to kexec, and nothing else?
> > > >
> > > > It should either be used for everything or for nothing. You have the
> > > > option to compile it in and then it should be used, and the option to
> > > > not compile it in and then it cannot be used.
> > > >
> > > > There are two basic use cases:
> > > >
> > > > (1) there is a vendor key which is very hard to use so you sign
> > > > something small and simple like shim with the vendor key, and sign your
> > > > kernel and modules with your own key that's typically enrolled with shim
> > > > MOK, and built into the kernel.
> > > >
> > > > (2) you import your key into the firmware, and possibly disable the
> > > > vendor key. You can load the kernel directly without shim, and then your
> > > > signing key is typically in the platform keyring and built into the
> > > > kernel.
> > > >
> > > > In neither case do I see any reason to use some keyrings for kexec and
> > > > other keyrings for modules.
> > >
> > > When building your own kernel there isn't a problem. Additional keys
> > > may be built into the kernel image, which are loaded onto the
> > > ".builtin_trusted_keys" keyring, and may be stored in MOK. Normally
> > > different keys are used for signing the kernel image and kernel
> >
> > That's actually not normal.
> >
> > > modules. Kernel modules can be signed by the build time ephemeral
> > > kernel module signing key, which is built into the kernel and
> > > automatically loaded onto the ".builtin_trusted_keys" keyring.
> >
> > Right, there is this advice to use ephemeral key to sign modules.
> >
> > I don't think that's a sound advice in general. It covers only the
> > special case when you build the kernel once, only rebuild the whole
> > kernel and never just one module, don't use any 3rd party module, don't
> > bother signing firmware (I am not sure that is supported right now but
> > if you are into integrity and stuff you can see that it makes sense to
> > sign it, too).
> >
> > And you need to manage the key you use for the kernel signing, anyway.
> > Sure, you could use the same ephemeral key as for the modules, enroll
> > it, and shred it but then it is NOT a key different from the one you use
> > for modules.
> >
> > Or you could maintain a long-lived key for the kernel, but if you do I
> > do NOT see any reason to not use it also for modules, in-tree and
> > out-of-tree.
>
> If signing ALL kernel modules, in-tree and out-of-tree, with the same
> key as the kernel image, is your real intention, then by all means
Why would you sign them with different keys, specifically?
For out of tree modules, sure. But that's an ADDITIONAL key, not
REMOVAL of a key.
> write a complete patch description with the motivation for why kernel
> module signatures need to be verified against this one pre-OS key
> stored only in the platform keyring. Such a major change like this
> shouldn't be buried here.
No, in my book it does not make sense to verify anything against the
pre-os key at all in the common case.
However, if you do verify the kernel against the pre-os key it does not
make sense to not verify modules against the pre-os key. There is no
sense using different key for kernel and modules. They are both built in
the same environment with access to same the keys.
> Otherwise, I suggest looking at Eric Snowberg's "Enroll kernel keys
> thru MOK patch set" patch set [1], as previously mentioned, which is
> queued to be upstreamed by Jarkko. It loads MOK keys onto the
> '.machine' keyring, which is linked to the '.secondary_trusted_keys"
> keyring. A subsequent patch set will enable IMA support.
I don't really care how many keyrings there are. What I care about is
that they are used conssitently.
Thanks
Michal
How's this series going? Did you and Mimi sort things out? Either way,
just wanted to let you kow you can base your changes on modules-testing
[0] if you want to resubmit for v5.19 (v5.18 will be too late already).
Once testing is done what is on modules-testing will go to modules-next
for testing for v5.19. There are no changes planned for v5.18 other than
fixes and so far there are none.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing
Luis
Hi Luis,
On Tue, 2022-03-22 at 10:37 -0700, Luis Chamberlain wrote:
> How's this series going? Did you and Mimi sort things out? Either way,
> just wanted to let you kow you can base your changes on modules-testing
> [0] if you want to resubmit for v5.19 (v5.18 will be too late already).
> Once testing is done what is on modules-testing will go to modules-next
> for testing for v5.19. There are no changes planned for v5.18 other than
> fixes and so far there are none.
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-testing
The "platform" keyring was upstreamed specifically to verify the kexec
kernel image. Orginally it contained only the UEFI db keys, but the MOK
keys were later added as well. Any other usage of the "platform" is
not planned.
To allow end users to sign their own kernel modules, executables, or
any other file, Eric Snowberg is working on a patch set to only load
the MOK CA keys onto the ".machine" keyring, which is linked to the
"secondary" keyring[1]. Verifying kernel modules based on certificates
signed by a MOK CA will then be possible.
thanks,
Mimi
[1]
https://lore.kernel.org/all/[email protected]/
Hi Mimi,
Sorry for bother you for this old topic.
On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Such?nek wrote:
> Hello,
>
> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > [Cc'ing Eric Snowberg]
> >
> > Hi Michal,
> >
> > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > adds support for use of platform keyring in kexec verification but
> > > support for modules is missing.
> > >
> > > Add support for verification of modules with keys from platform keyring
> > > as well.
> >
> > Permission for loading the pre-OS keys onto the "platform" keyring and
> > using them is limited to verifying the kexec kernel image, nothing
> > else.
>
> Why is the platform keyring limited to kexec, and nothing else?
>
> It should either be used for everything or for nothing. You have the
> option to compile it in and then it should be used, and the option to
> not compile it in and then it cannot be used.
>
> There are two basic use cases:
>
> (1) there is a vendor key which is very hard to use so you sign
> something small and simple like shim with the vendor key, and sign your
> kernel and modules with your own key that's typically enrolled with shim
> MOK, and built into the kernel.
>
> (2) you import your key into the firmware, and possibly disable the
> vendor key. You can load the kernel directly without shim, and then your
> signing key is typically in the platform keyring and built into the
> kernel.
>
In the second use case, if user can enroll their own key to db either before
or after hardware shipping. And they don't need shim because they removed
Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to
them for trusting db keys for verifying kernel module, or for IMA (using CA
in db)?
In the above use case for distro, partner doesn't need to re-compiler distro
kernel. They just need to re-sign distro kernel and modules. Which means
that the partner trusted distro. Then the partner's key in db can be used to
verify kernel image and also kernel module without shim involve.
Regards
Joey Lee
> On Mar 28, 2022, at 4:15 AM, joeyli <[email protected]> wrote:
>
> Hi Mimi,
>
> Sorry for bother you for this old topic.
>
> On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
>> Hello,
>>
>> On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
>>> [Cc'ing Eric Snowberg]
>>>
>>> Hi Michal,
>>>
>>> On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
>>>> Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
>>>> adds support for use of platform keyring in kexec verification but
>>>> support for modules is missing.
>>>>
>>>> Add support for verification of modules with keys from platform keyring
>>>> as well.
>>>
>>> Permission for loading the pre-OS keys onto the "platform" keyring and
>>> using them is limited to verifying the kexec kernel image, nothing
>>> else.
>>
>> Why is the platform keyring limited to kexec, and nothing else?
>>
>> It should either be used for everything or for nothing. You have the
>> option to compile it in and then it should be used, and the option to
>> not compile it in and then it cannot be used.
>>
>> There are two basic use cases:
>>
>> (1) there is a vendor key which is very hard to use so you sign
>> something small and simple like shim with the vendor key, and sign your
>> kernel and modules with your own key that's typically enrolled with shim
>> MOK, and built into the kernel.
>>
>> (2) you import your key into the firmware, and possibly disable the
>> vendor key. You can load the kernel directly without shim, and then your
>> signing key is typically in the platform keyring and built into the
>> kernel.
>>
>
> In the second use case, if user can enroll their own key to db either before
> or after hardware shipping. And they don't need shim because they removed
> Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to
> them for trusting db keys for verifying kernel module, or for IMA (using CA
> in db)?
>
> In the above use case for distro, partner doesn't need to re-compiler distro
> kernel. They just need to re-sign distro kernel and modules. Which means
> that the partner trusted distro. Then the partner's key in db can be used to
> verify kernel image and also kernel module without shim involve.
If shim is used, the new machine keyring can be used to solve this problem.
This pull request [1] allows additional certificates to be loaded into the MOKList
without going through MokManager. Have the end-user/partner create a
shim_certificate.efi containing their key. Then sign it with their DB key. When
shim boots, it will validate shim_certificate.efi against the DB key and load the
key contained within it into the MOKList. Now both module and kernel validation
can be performed with this key, since it is contained within the machine keyring.
[1] https://github.com/rhboot/shim/pull/446