Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

From: David Howells
Date: Thu Aug 16 2018 - 08:14:00 EST

Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:

> Now this patch changed it to trusting builtin_trusted_keys by default,
> and all the other keys go to secondary_trusted_keys kerying. And that
> probably explains why it broke.
> So checking for keys in both the keyrings makes sense to me.
> I am wondering why did we have to split this keyring to begin with.
> So there are use cases where we want to trust builtin keys but
> not the ones which came from other places (UEFI secure boot db, or
> user loaded one)?

IMA and the IMA authors. They want everything separated into separate
keyrings out by source and usage as far as I can tell - though this just makes
it harder to use things.

One advantage of splitting things, though, is that you don't lose the built-in
keys if you load a conflicting one from another source.

One thing that's on my to-do list is to mark keys with the provenance, perhaps
something like:

enum key_source {

struct key {
enum key_source source;


(1) pass this information to LSMs to make use of

(2) Make the verification code take a bitmask of what keys are permitted for
the task at hand.