Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> The same thing is true of some lockdown patch. Maybe it's a good thing
> in general. But whether it's a good thing is _entirely_ independent of
> any secure boot issue. I can see using secure boot without it, but I
> can very much also see using lockdown without secure boot.
>
> The two things are simply entirely orthogonal. They have _zero_
> overlap. I'm not seeing why they'd be linked at all in any way.
I'm not sure I agree. Here's my reasoning:
(1) Lockdown mode really needs to activated during kernel boot, before
userspace has a chance to run, otherwise there's a window of opportunity
in which the kernel *isn't* locked down.
(2) If the kernel isn't booted in secure boot mode, then there's the
opportunity to tamper before the kernel even starts booting.
(3) There doesn't seem any point in booting in secure boot mode if you don't
protect the running kernel image against tampering. What does it mean to
be in "secure boot mode" in that case? If the kernel can be tampered
with, it would seem to be, by definition, insecure.
(4) You can't validly promise the next OS you kexec that *it* is started in
secure boot mode if you don't stop your image from being tampered with.
Note that this doesn't prevent a compromised kernel from lying to the
next OS.
(5) Tampering with a running kernel can be achieved in a variety of ways:
loading of arbitrary modules, loading of modified firmware, direct access
to devices that can effect DMA, writing to /dev/mem, ...
(6) We need to be able to load modules and firmware, but these can be signed,
hashed or measured so we have some idea of their provenance - but signing
can be worked around if, say, /dev/mem is writable.
(7) If you told the BIOS[*] that you want to be in secure boot mode, then the
kernel should honour that and try to prevent tampering with the image.
(8) Turning lockdown mode on if the kernel is booted in secure boot seems to
be the way to achieve this.
(9) BIOS vendors can blacklist any of the components - say the SHIM - to
prevent an insecure kernel from being used to compromise and kexec
another OS.
Note that I've provided a kernel command line parameter that will turn
lockdown mode on arbitrarily - but that can be turned off by editing the
parameters in grub.cfg, say.
David
[*] Yeah, I know, this is an x86-centric view.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
