Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1693601imm; Wed, 8 Aug 2018 23:54:33 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwAvBekl006kY1YJ5KcY2sAdKuOQQhA0CKSplGj8ZCZRk6On5jJDY2nZy0PSytDQeRpXm9q X-Received: by 2002:a17:902:1c8:: with SMTP id b66-v6mr882515plb.273.1533797673313; Wed, 08 Aug 2018 23:54:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533797673; cv=none; d=google.com; s=arc-20160816; b=M0simyMFa5+C2JXX1ULUPfSc8sP1If+E4jwJoVDHemZuywNFDztaP3qy+/LkcwlIrT P8oclph04oB+PxiGv2bqYItPxbFiTUKXaBO9ZjNoAq0WAdNBMLH9VQA0IQYPwS1/Pj55 c5iCh8h09bWxMqbdCklVsf1nZt9VmbdZt6Qj9BcNCRtsY3okpkR+eCZBA6zJ+dy95gSc ABXiS/R4WaJ0jiEae62CXMCkGI2t7mxtJ4BxRMW1ygAGsjOKImBMnebUkIaM1o5+i2Il eOYhQmThGyr2rcx9ZIgPWQpPxwhcuavZs5bnY7PlZcuZR46KmnTM6MH6Cyyxxx/hUrcP slcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=PNU4OnbPxDJVNsyft9MVZpsTuUXxmsro2/V2+VBJwWs=; b=QdWBwzp460rZrSHF/yxtMuV2dv5KSwP4EufDcVwTmf9PHIchU9oZhaXsNqYUPCkick G2KHtkGx9054/5cPImpYvVonJb0Z2adRE3tmPotSvC8HfHU4/QTQRy/vufHZ5XI5WpCs lCvcD6EVEXgslmDMkbmvnskSq7y0JSj33w+zefjjiYoNg42zeoPCjiOW+nuIrQ0znzHR UcHrEZNO0ndhm1fBGhb3c/+iqzX5M6o4iWnQqdU7572FZWyeDWozpfJHYt1qb7PPplmO wj2EaQ56Om/8iqIt2YJxbQvfP7zKHLQ6kmS+tjX5Dzo2cbOycILsOSapKoFxBS6v/ZV6 FrLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c17-v6si6036479pgg.628.2018.08.08.23.54.18; Wed, 08 Aug 2018 23:54:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728596AbeHIJQd (ORCPT + 99 others); Thu, 9 Aug 2018 05:16:33 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:53132 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727559AbeHIJQc (ORCPT ); Thu, 9 Aug 2018 05:16:32 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 14E878062B; Thu, 9 Aug 2018 08:53:06 +0200 (CEST) Date: Thu, 9 Aug 2018 08:53:06 +0200 From: Pavel Machek To: Yu Chen Cc: Ryan Chen , jlee@suse.com, oneukum@suse.com, "Rafael J. Wysocki" , ebiggers@google.com, Theodore Ts'o , smueller@chronox.de, denkenz@gmail.com, Linux PM list , linux-crypto@vger.kernel.org, Linux Kernel Mailing List , kookoo.gu@intel.com, Zhang Rui Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Message-ID: <20180809065306.GA24201@amd> References: <1532590246.7411.3.camel@suse.com> <20180726081404.GG4244@linux-l9pv.suse> <20180730170415.GQ4244@linux-l9pv.suse> <20180803033702.GB416@sandybridge-desktop> <20180803053445.GC4244@linux-l9pv.suse> <20180805100200.GB22948@amd> <20180806084534.GB12124@chenyu-desktop> <20180808175036.GA16217@amd> <20180809030135.GA21364@chenyu-desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <20180809030135.GA21364@chenyu-desktop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > Define unsafe. > >=20 > > If you want security against bad people resuming your machines, please > Yes, this is one of the requirements. > > But I thought you were trying to do something for secure boot, and "bad > > person resumes your machine" is out of scope there. > >=20 > Not exactly, secure boot is one solution to meet the requirement. Is it? AFAICT secure boot is something else. "Not even owner can see kernel memory". > > So please always explain security against _what kind of attack_ you > > are trying to improve; intelligent communication is not possible > > without that. > >=20 > User requirement: > A is the user, B is the attacker, user A launches a STD and > encrypts A's ram data, then writes these encrypted data onto > the disk, so that: Even if user B has access to the disk, > B could not know the content of A. Which implies: > 1. If B unplugs the disk from A's machine, and plugs the disk onto > another machine, B could not decode the content without A's > 'permission'. > 2. If B is using the same machine as A, even A has walked away leaving > the system suspend, B could not resume to A's context without > A's 'permission'. Ok. Let's call this "effective resume password". > Previously, there are three proposal for this: > a. Enhance the uswsusp(Pavel) Actually you don't have to enhance anything. Uswsusp already provides "effective resume password". If you only want to ask for password on resume, RSA is needed. > Then let's talk a little more about secure boot. According > to my understanding, the situation secure boot tries to deal > with is a little different from the user case we raised above - > It is an enhancement for case 1, because it refuses to resume > once the machine is changed. And it does not cover case 2. But > if it is a requirement from the user, that's ok. That does not match my understanding of secure boot. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEARECAAYFAltr5NIACgkQMOfwapXb+vK4zACggeM5cg14StvKcoK9EU+6eGLp e5QAmLIzAxViZsXEdTTFXtBoQWAO0gM= =8X+b -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1--