[GIT PULL] Kernel lockdown for secure boot

[Andy Lutomirski]

I've reordered your email to make my email more coherent.

> On Apr 4, 2018, at 1:05 AM, David Howells <dhowells at redhat.com> wrote:
>

>
> What we *have* said is that *if* we want to pass the secure boot state across
> kexec, then we have to make sure that:
>

What do you even mean "pass the secure boot state across kexec"?  All
I can come up with is that you want a kexeced Linux kernel to also be
passed a flag saying "I was secure booted" and to enable or disable
lockdown accordingly.  Let's consider the cases:

1. First kernel is verified (secure boot or otherwise) and locked
down.  Certainly that lock down needs to enforce that the next kernel
in the chain is locked down, otherwise lockdown gets defeated.

2. First kernel is not verified but is locked down.  It still needs to
enforce that the next kernel is verified and locked down, otherwise
lockdown gets defeated.

3. First kernel is verified but not locked down.  There's very little
point in trying to force the next kernel to be locked down.

4. First kernel is neither verified nor locked down.  There's still no
point in trying to force the next kernel to be locked down.

Isn't the right solution to have a flag saying "force lockdown" that
kexec can pass to the child kernel?  A locked down parent kernel would
refuse to load an unsigned child kernel and would always set that
flag.

> Andy Lutomirski <luto at kernel.org> wrote:
>
>> As far as I can tell, what's really going on here is that there's a
>> significant contingent here that wants to prevent Linux from
>> chainloading something that isn't Linux.
>
> You have completely the wrong end of the stick.  No one has said that or even
> implied that.  You are alleging dishonesty on our part.

I'm alleging that the idea that Linux seems some particular policy to
avoid being blacklisted keeps being brought up as a justification for
these patches.  And, in fact, you bring it up again right here:

>
> And if someone tampers with the aim of breaking, say, Windows, then someone,
> e.g.  Microsoft, might blacklist the shim.

In other words, if you chainload an intentionally corrupted copy of
Windows, you get blacklisted?  This sounds awfully like what I said
upthread.  Is this actually a real concern?  Greg seems quite
convinced that it isn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html