linux-kernel - Re: [RFC] Second attempt at kernel secure boot support

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, 01 Nov 2012 15:02:25 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Pavel Machek <pavel@....cz>
CC:	Eric Paris <eparis@...isplace.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Jiri Kosina <jkosina@...e.cz>, Oliver Neukum <oneukum@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support

On 11/01/2012 02:27 PM, Pavel Machek wrote:

> Could someone write down exact requirements for Linux kernel to be signed by Microsoft?
> Because thats apparently what you want, and I don't think crippling kexec/suspend is
> enough.

As I understand it, the kernel won't be signed by Microsoft.

Rather, the bootloader will be signed by Microsoft and the vendors will 
be the ones that refuse to sign a kernel unless it is reasonably assured 
that it won't be used as an attack vector.

If you want fully-open behaviour it's still possible, you just need to 
turn off secure boot.

With secure boot enabled, then the kernel should refuse to let an 
unsigned kexec load new images, and kexec itself should refuse to load 
unsigned images.  Also the kernel would need to sign its 
"suspend-to-disk" images and refuse to resume unsigned images.

Presumably the signing key for the "suspend-to-disk" images would need 
to be stored somewhere that is not accessable even by root.  It's not 
clear to me how we would do this, but maybe it's possible with hardware 
support.

Chris
--
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/