From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 04 Apr 2018 10:43:57 -0500 Subject: [GIT PULL] Kernel lockdown for secure boot In-Reply-To: <20736.1522829117@warthog.procyon.org.uk> (David Howells's message of "Wed, 04 Apr 2018 09:05:17 +0100") References: <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> <20736.1522829117@warthog.procyon.org.uk> Message-ID: <87fu4bj7sy.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org David Howells writes: > Andy Lutomirski 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. > > What we *have* said is that *if* we want to pass the secure boot state across > kexec, then we have to make sure that: > > (1) no one tampers with the intermediate kernel between boot and kexec > otherwise the secure boot state is effectively invalidated, and > > (2) the image that gets kexec'ed is trusted. > > Remember: you cannot know (2) if you don't have (1). > > And if someone tampers with the aim of breaking, say, Windows, then someone, > e.g. Microsoft, might blacklist the shim. *Wow* You just denied this isn't about not booting Windows and a few lines later said that is your concern. I was thinking I would have to dig up old archives where I had been told this before, but you just nicely repeated all of the old arguments so I don't see the point. Eric -- 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