On Thu, Nov 10, 2022 at 12:54:43AM +0000, Eric Snowberg wrote:
quoted
On Nov 9, 2022, at 5:01 PM, Morten Linderud [off-list ref] wrote:
On Tue, Nov 23, 2021 at 11:41:23PM -0500, Eric Snowberg wrote:
quoted
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@oracle.com/#24453409
If we could support both the EFI variables and the EFI configuration table setup
it would hopefully be easier for others to implement the interface? I wouldn't
mind trying to write a patch for that if others think it's a good idea.
I'm not really sure what Peter means with "much more reliable" though.
--
Morten Linderud
PGP: 9C02FF419FECBE16