From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [GIT PULL] Kernel lockdown for secure boot Date: Wed, 04 Apr 2018 16:20:43 +0000 Message-ID: References: <20180404125743.GB16242@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180404125743.GB16242@thunk.org> Sender: linux-kernel-owner@vger.kernel.org To: tytso@mit.edu, Linus Torvalds , luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi List-Id: linux-api@vger.kernel.org On Wed, Apr 4, 2018 at 5:57 AM Theodore Y. Ts'o wrote: > 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? It does - I was talking about the non-lockdown case. In the lockdown case you can only kexec images you trust, so there's no problem. Red Hat have been shipping a signed kdump image for years.