From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto@kernel.org (Andy Lutomirski) Date: Tue, 3 Apr 2018 16:48:31 -0700 Subject: [GIT PULL] Kernel lockdown for secure boot In-Reply-To: <10718.1522798745@warthog.procyon.org.uk> References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> <10718.1522798745@warthog.procyon.org.uk> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Apr 3, 2018 at 4:39 PM, David Howells wrote: > Linus Torvalds 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. That's simply not true. A sensible verified boot chain (a la Chrome OS) is likely to load, as one verified chunk, a kernel and initramfs. Then initramfs can flip on lockdown all by itself before it enables networking or any other attack vectors. -- 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