linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Feb 2013 08:57:33 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	David Howells <dhowells@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Josh Boyer <jwboyer@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries

* Greg KH:

> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
>> Because Microsoft have indicated that they'd be taking a reactive 
>> approach to blacklisting and because, so far, nobody has decided to 
>> write the trivial proof of concept that demonstrates the problem.
>
> So, once that proof is written, suddenly all of the working Linux
> distros's keys will be revoked?

The counterargument to that is that Microsoft will not proactively
revoke UEFI drivers, only drivers which are actually abused.

As far as I know, there is no public commitment to this revocation
policy.  It makes sense, given the limited revocation space, but
that's all.

> I don't buy it.  Yes, I understand this is your position, and has been
> all along, and _maybe_ you can extend it to "we should sign our kernel
> modules", but to take it farther than that, like the list David has
> described, is not required by anyone here.

It's a logical extrapolation based on the technical specification.
I've been guilty of the same mistake, if you want to call it that way.
Basically, we're making up concrete security objectives because the
existing documentation doesn't provide them, and write our code
according to that.  But we can easily guess wrong, in both directions.

In any case, there's another reading of the UEFI Secure Boot
requirements: you may run any code you wish after calling
ExitBootServices().  That could be an unsigned, traditional GRUB.  But
this will not generally address the issue of dual-booting Windows 8 in
such a way that Windows sees that the device has enabled Microsoft
Secure Boot.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/