On Tue, Apr 3, 2018 at 12:49 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxx> wrote: > >> >>> A kernel that allows users arbitrary access to ring 0 is just an >> >>> overfeatured bootloader. Why would you want secure boot in that case? >> >> >> >> To get a chain of trust. >> > >> > You don't have a chain of trust that you can trust in that case. >> > >> Please elaborate on why I can’t trust it. > > If the user can arbitrarily modify the running kernel image, you cannot trust > anything. You cannot determine the trustworthiness of something because your > basis for determining that trust can be compromised. I'm having a very, very hard time coming up with a scenario where I can "trust" something if an attacker can get root but can't modify the running kernel image but I can't "trust" something if the attacker can't. About the only think I can come up with is that root generally has a hard time directly reading kernel keyring data. But if we really think that kernel keyring data is so sacred, let's please solve it properly using SGX or some hypervisor doodad like Microsoft's Credential Guard. Protecting the keyring with lockdown is a whole lot of annoyance without all that much gain. > >> Please also elaborate on how lockdown helps at all. > > Stopping the kernel from being arbitrarily modified allows you to preserve > your trust. If I build a voting machine, an ATM, or a server that runs Panera Bread's website, I can certainly issue a press release that says "hey, the bad guy just downloaded tens of millions of customer records, but they didn't actually get to run CPL0 code, so all is well." </sarcasm> > > Stopping the kernel from being arbitrarily read stops any encryption keys it > may be using from being retrieved. If I build a server that runs Panera Bread 2.0's website, and the attacker exploits my machine to steal tens of millions of customer records by getting the machine to talk to some database server using keys that are securely stored in the kernel keyring, I would feel sooooooo much better knowing that the attacker didn't also manage to extract the key that lets the machine talk to the database server. Never mind that the attacker already stole the entire contents of the database. </sarcasm> -- 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
