Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932486Ab2KAVCy (ORCPT ); Thu, 1 Nov 2012 17:02:54 -0400 Received: from exprod7og103.obsmtp.com ([64.18.2.159]:50735 "EHLO exprod7og103.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759940Ab2KAVCs (ORCPT ); Thu, 1 Nov 2012 17:02:48 -0400 Message-ID: <5092E361.7080901@genband.com> Date: Thu, 01 Nov 2012 15:02:25 -0600 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: Pavel Machek CC: Eric Paris , James Bottomley , Jiri Kosina , Oliver Neukum , Alan Cox , Matthew Garrett , Josh Boyer , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org Subject: Re: [RFC] Second attempt at kernel secure boot support References: <1348152065-31353-1-git-send-email-mjg@redhat.com> <2548314.3caaFsMVg6@linux-lqwf.site> <50919EED.3020601@genband.com> <36538307.gzWq1oO7Kg@linux-lqwf.site> <1351760905.2391.19.camel@dabdike.int.hansenpartnership.com> <1351762703.2391.31.camel@dabdike.int.hansenpartnership.com> <1351763954.2391.37.camel@dabdike.int.hansenpartnership.com> <20121101202701.GB20817@xo-6d-61-c0.localdomain> In-Reply-To: <20121101202701.GB20817@xo-6d-61-c0.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2012 21:02:27.0277 (UTC) FILETIME=[32DE77D0:01CDB874] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-19330.002 X-TM-AS-Result: No--1.424400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1319 Lines: 31 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/