Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753455Ab3IZO4m (ORCPT ); Thu, 26 Sep 2013 10:56:42 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56529 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753416Ab3IZO4f (ORCPT ); Thu, 26 Sep 2013 10:56:35 -0400 Date: Thu, 26 Sep 2013 16:56:33 +0200 From: Vojtech Pavlik To: Jiri Kosina Cc: James Bottomley , Pavel Machek , Alan Stern , David Howells , "Lee, Chun-Yi" , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, linux-pm@vger.kernel.org, linux-crypto@vger.kernel.org, opensuse-kernel@opensuse.org, "Rafael J. Wysocki" , Matthew Garrett , Len Brown , Josh Boyer , Matt Fleming , Greg KH , Rusty Russell , Herbert Xu , "David S. Miller" , "H. Peter Anvin" , Michal Marek , Gary Lin , Vivek Goyal , "Lee, Chun-Yi" Subject: Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot Message-ID: <20130926145633.GA572@suse.cz> References: <1380147414.18835.36.camel@dabdike.int.hansenpartnership.com> <20130926002730.GA26857@amd.pavel.ucw.cz> <1380162771.18835.47.camel@dabdike.int.hansenpartnership.com> <1380206654.18835.56.camel@dabdike.int.hansenpartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bounce-Cookie: It's a lemon tree, dear Watson! User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1698 Lines: 43 On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote: > > The only two problems I see are > > > > 1. The key isn't generational (any compromise obtains it). This > > can be fixed by using a set of keys generated on each boot and > > passing in both K_{N-1} and K_N > > I think this could be easily made optional, leaving the user with choice > of faster or "safer" boot. Ideally, the key should be regenerated on each true reboot and kept the same if it is just a resume. Unfortunately, I don't see a way to distinguish those before we call ExitBootServices(). The reasoning behind that is that in the case of a kernel compromise, a suspended-and-resumed kernel will still be compromised, so there is no value in passing it a new key. A freshly booted kernel, though, should get a new key, exactly because the attacker could have obtained a key from the previous, compromised one. This speeds up the ususal suspend-and-resume cycle, but provides full security once the user performs a full reboot. The question that remains is how to tell in advance. > > 2. No external agency other than the next kernel can do the > > validation since the validating key has to be secret > > This is true, but as you said, the relevance of this seems to be rather > questionable. Indeed, it's hard to imagine a scenario that is also valid within the secure boot threat model. -- Vojtech Pavlik Director SUSE Labs -- 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/