Thread (80 messages) 80 messages, 17 authors, 2019-07-11

Re: [PATCH V34 09/29] kexec_file: Restrict at runtime if the kernel is locked down

From: Matthew Garrett <hidden>
Date: 2019-06-27 15:28:23
Also in: kexec, linux-api, lkml

On Wed, Jun 26, 2019 at 9:59 PM James Morris [off-list ref] wrote:
This is not a criticism of the patch but a related issue which I haven't
seen discussed (apologies if it has).

If signed code is loaded into ring 0, verified by the kernel, then
executed, you still lose your secure/trusted/verified boot state. If the
currently running kernel has been runtime-compromised, any signature
verification performed by the kernel cannot be trusted.

This problem is out of scope for the lockdown threat model (which
naturally cannot include a compromised kernel), but folk should be aware
that signature-verified kexec does not provide equivalent assurance to a
full reboot on a secure-boot system.
By that metric, on a secure boot system how do we determine that code
running in the firmware environment wasn't compromised before it
launched the initial signed kernel?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help