Hi all,
There's an interesting issue with the way the x86 boot parameters are passed
into the kernel if we want to store the secure-boot mode flag in there.
My patches add boot_params->secure_boot, into which is placed the secure boot
mode as deduced by the EFI boot wrapper, if it is invoked. This, however,
gets scrubbed by sanitize_boot_params() if the ->sentinel flag is set. It
turns out that grub2 has a bug in it whereby it initialises boot_params by
copying the wrong stuff over it, thereby setting the ->sentinel flag.
In my patch I saw that sanitisation was happening and I stopped
sanitize_boot_params() from clobbering that particular byte and instead zeroed
it on entry to the boot wrapper. This seemed reasonable since the boot
wrapper calculates the flag and simply overwrites whatever the boot loader had
placed there - and the value was getting clobbered by sanitisation called
during kernel decompression.
Matt argues, however, that boot_params->secure_boot should be propagated from
the bootloader and if the bootloader wants to set it, then we should skip the
check in efi_main() and go with the bootloader's opinion. This is something
we probably want to do with kexec() so that the lockdown state is propagated
there.
However, what should happen in the core kernel if the bootloader doesn't
properly initialise ->sentinel and sanitisation is done that then clobbers
->secure_boot? Should the kernel be locked down by default or left open by
default if lockdown was enabled in the kernel config?
But, as I mentioned, a bug in grub2 whereby it is copying the wrong
initialisation data over boot_params is causing sanitisation to be triggered.
Some questions that should clarify how we proceed:
(1) Do we actually want to propagate the mode determination from the boot
loader?
(2) Do we have to determine the secure-boot status in the EFI boot wrapper
(we don't use it there) or can we determine it in the core kernel?
(3) What's the default mode in the case of sanitisation when lockdown is
configured?
(4) How do we handle the initialisation being mucked up such that ->sentinel
ends up 0 and ->secure_boot ends up essentially random?
Any thoughts?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
