Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot | Date | Thu, 16 Aug 2018 14:51:27 +0100 |
| |
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > I see that module signing code trusts only builtin keys and > > not the keys in secondary_trusted_keys keyring. > > This, I think, makes sense. > > It basically says: we don't allow modules that weren't built with the > kernel. Adding a new key later and signing a module with it violates > that premise.
At the risk of starting another flamewar...
The problem with that is that it means you can't load third party modules - such as the NVidia driver. That's fine if you absolutely reject the right of people to produce third party drivers for the Linux kernel and absolutely require that they open and upstream their code if they want in.
One of the reasons *for* letting modules be loaded using UEFI keys is that this allows you to load signed third-party drivers without needing to manually re-sign your shim, grub and kernel.
But this is not something we can ask most ordinary users to do (not least because of key material security) - and they would have to at least partially repeat the process every time one of those components is upgraded. One of the jobs of a distribution is to insulate the ordinary user from this.
And before anyone says "well, the distribution should just build and sign $THIRD_PARTY_MODULE", there are issues with that that potentially come with lawyers attached.
Further, if you want to go down the route of restricting the use of UEFI keys to load modules because that might allow someone to run hacked code, then you also can't let kexec use UEFI keys because that would then be able to run hacked code too.
As an alternative, though, maybe it would make sense to allow TPM-based keys to be used to verify modules. The problem there is that it doesn't prevent the signing process from being interfered with on an already-hacked box.
David
| |