> On Nov 9, 2022, at 5:01 PM, Morten Linderud <morten@xxxxxxxxxxx> wrote: > > On Tue, Nov 23, 2021 at 11:41:23PM -0500, Eric Snowberg wrote: >> A new Machine Owner Key (MOK) variable called MokListTrustedRT has been >> introduced in shim. When this UEFI variable is set, it indicates the >> end-user has made the decision themselves that they wish to trust MOK keys >> within the Linux trust boundary. It is not an error if this variable >> does not exist. If it does not exist, the MOK keys should not be trusted >> within the kernel. > > Hi Eric, > > I've been milling around on this patch-set for a while and I have a few issues > with the description of the commit and what the code actually does. > > efi_mokvar_entry_find doesn't simply read an UEFI variable as the commit message > suggests, it will look for the MOK variable loaded into the EFI configuration > table. This implies we need this table setup in early boot to take usage of this > patch set. > > The only bootloader that does setup this table, is the `shim` as described. But > no other bootloader implements support for the MOK EFI configuration table. > > This effectively means that there is still no way for Machine Owners to load > keys into the keyring, for things like module signing, without the shim present > in the bootchain. I find this a bit weird. > > Is this an intentional design decision, or could other ways be supported as > well? In v6 I had it as a RT variable, during the review a request was made [1] to just use the EFI configuration table. If there are other boot loaders that want to use this, I don’t see why the code in v6 couldn’t be added back. If the configuration table isn’t available, it could try reading the RT var next. 1. https://patchwork.kernel.org/project/linux-integrity/patch/20210914211416.34096-13-eric.snowberg@xxxxxxxxxx/#24453409
