Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753349AbbDFUv5 (ORCPT ); Mon, 6 Apr 2015 16:51:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39887 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753237AbbDFUvr (ORCPT ); Mon, 6 Apr 2015 16:51:47 -0400 Date: Mon, 6 Apr 2015 16:51:45 -0400 From: Mike Snitzer To: Pavel Machek Cc: Pali =?iso-8859-1?Q?Roh=E1r?= , Alasdair Kergon , Neil Brown , "Rafael J. Wysocki" , Len Brown , dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH 0/3] dm-crypt: Adds support for wiping key when doing suspend/hibernation Message-ID: <20150406205145.GA19677@redhat.com> References: <1428254419-7334-1-git-send-email-pali.rohar@gmail.com> <20150406130045.GA18583@redhat.com> <20150406132505.GB9978@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150406132505.GB9978@amd> 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: 1729 Lines: 36 On Mon, Apr 06 2015 at 9:25am -0400, Pavel Machek wrote: > On Mon 2015-04-06 09:00:46, Mike Snitzer wrote: > > On Sun, Apr 05 2015 at 1:20pm -0400, > > Pali Roh?r wrote: > > > > > This patch series increase security of suspend and hibernate actions. It allows > > > user to safely wipe crypto keys before suspend and hibernate actions starts > > > without race conditions on userspace process with heavy I/O. > > > > > > To automatically wipe cryto key for before hibernate action call: > > > $ dmsetup message 0 key wipe_on_hibernation 1 > > > > > > To automatically wipe cryto key for before suspend action call: > > > $ dmsetup message 0 key wipe_on_suspend 1 > > > > > > (Value 0 after wipe_* string reverts original behaviour - to not wipe key) > > > > Can you elaborate on the attack vector your changes are meant to protect > > against? The user already authorized access, why is it inherently > > dangerous to _not_ wipe the associated key across these events? > > Umm. You are using your notebook. It is unlikely to be stolen at that > point. You close the lid and board the airplane, stowing it in > overhead bin. There's much better chance of notebook being stolen now. Yes, pretty straight forward but the thief would need to then login upon resume (at least with most common desktop configs)... the barrier then is only the strength of the user's password and not the crypt passphrase. -- 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/