I've reordered your email to make my email more coherent. > On Apr 4, 2018, at 1:05 AM, David Howells <dhowells@xxxxxxxxxx> 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@xxxxxxxxxx> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
