From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso@mit.edu (Theodore Y. Ts'o) Date: Wed, 4 Apr 2018 08:57:43 -0400 Subject: [GIT PULL] Kernel lockdown for secure boot In-Reply-To: References: Message-ID: <20180404125743.GB16242@thunk.org> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > What I'm afraid of is this turning into a "security" feature that ends up > being circumvented in most scenarios where it's currently deployed - eg, > module signatures are mostly worthless in the non-lockdown case because you > can just grab the sig_enforce symbol address and then kexec a preamble that > flips it back to N regardless of the kernel config. Whoa. Why doesn't lockdown prevent kexec? Put another away, why isn't this a problem for people who are fearful that Linux could be used as part of a Windows boot virus in a Secure UEFI context? If lockdown simply included a requirement for a signed kernel for kexec --- and if kernel signing aren't available, to simply not alow kexec, wouldn't that take care of this case? This wouldn't even be all that much of a burden for non-distro users with lockdown enabled, since in my experience outside of enterprise and data center use cases, kexec isn't used --- and in fact, very often kexec doesn't even work outside of a very carefully selected and bug-fixed set of device drivers. (It often doesn't work in non-distro kernels because very few upstream developers really care about kexec.) - Ted -- 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