Re: [RFC PATCH 07/16] efi: Public the function of transferring EFI status to kernel error
On Thu, 30 Jul 2015 17:23:22 +0100, Matt Fleming said: > On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote: > > Moved the function of transferring EFI status to kernel error for > > later used by EFI stub. > > > > Signed-off-by: Lee, Chun-Yi > > --- > > drivers/firmware/efi/vars.c | 33 - > > include/linux/efi.h | 33 + > > 2 files changed, 33 insertions(+), 33 deletions(-) > > The patch contents are fine but the title could do with some work, > "public" isn't a verb. In English, any noun can be verbed. :) -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: > Given that we know that people want signed binaries without blocking kexec, > you > should have '1' just enforce module signing and '2' (or higher) implement a > full > lockdown including kexec. > Or, eliminate the -1 permanently insecure option and make this a bitmask, if > someone wants to enable every possible lockdown, have them set it to "all > 1's", > define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. pgpxQY_kaW9gQ.pgp Description: PGP signature
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said: > So, this is my final attempt at providing the functionality I'm interested > in without inherently tying it to Secure Boot. There's strong parallels > between the functionality that I'm interested in and the BSD securelevel > interface, so here's a trivial implementation. Although all the individual patches look like sane and reasonable things to do, I'm not at all convinced that sticking them all under control of one flag is really the right way to do it. In particular, there probably needs to be some re-thinking of the kexec, signed-module, and secure-boot stuff, as it's still a moving target. > So, this is my final attempt at providing the functionality I'm interested > in without inherently tying it to Secure Boot. You may as well bite the bullet on this one, and tie it together. Without Secure Boot, by the time your code runs it's already too late. That's the whole point of Secure Boot, after all. pgpe8NfrvaPO7.pgp Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 03:12:19 +, Matthew Garrett said: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > > You have it backwards. The conclusion here is that having a case where > > a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. You *do* realize that the fact you have some set of customers who perform non-interactive installs does *not* imply that being able to do so is a given, right? The fact it is available and doable for your customers does *not* mean it's available and doable in general. There's a big difference between "the design has to deal with the fact that some customers can do this on some subsets of hardware" and "the design is free to assume that this is doable". pgpBN7FFuPJ8C.pgp Description: PGP signature
