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 15:43:50 +0100 |
| |
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> I've told you several times you can't use the secure boot keys for any form > of trust beyond boot,
Yes - and you've been told several times that you're wrong.
As far as I can tell, you seem to think that whilst keys from the UEFI storage could be used to verify a hacked module, they couldn't be used to verify a hacked boot-time component (shim, grub, kernel, etc.).
However, if you can load a hacked module, you can very likely replace the shim, say, with a hacked one. In fact, replacing the shim may be easier because modules are tied to their parent kernel in other ways besides the signing key, whereas a shim must be standalone.
I will grant, however, that it I can understand a desire to reduce the attack surface by not trusting the UEFI keys beyond booting - but then you shouldn't use them for kexec *either*.
> Personally, I don't see any use for the UEFI keys in the kernel beyond > kexec
Allowing you to load the NVidia module, say, into the kernel without the distribution having to build it in with the kernel.
David
| |