Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1684095imm; Thu, 19 Jul 2018 06:15:17 -0700 (PDT) X-Google-Smtp-Source: AAOMgpecQtp0lSgnSW25svP1bv/p5yj/ClI+TgOB2KCxy4hbRDuTV9egMLxdWDtFUiBZ7/l5Lu6q X-Received: by 2002:a17:902:760d:: with SMTP id k13-v6mr9988257pll.56.1532006117215; Thu, 19 Jul 2018 06:15:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532006117; cv=none; d=google.com; s=arc-20160816; b=AwSL2XkHDxcXVcQi9avPyUMFKdATgB5BPvixgPe2X3iOSshhxPuUANq5gAzaJqUoQo /LnNZQdgbdfUKwJyEbjMv05Q9avR0Ht0MWqrCz41gjfeC7/SAq+gcI45dGIBEfA4f71B hy2uqXudIiESVNNw/qNoEjKjnAVWjPUGai41iBUMz6dbSjh+8AIkV92bnsmenq7KQ7FF wwch5mohAEPNAL11IxvnZ16ivFKjU1G3mL0aLjKsWxyTpbJc0+v4UObtMhp5KUJ5F5tr y5U1HeMQU0VPd8fDhOIt4c+9HXrPD6Z70xWIoXlr9x57LJq3mkSyQc4h9FzwtAT4Cn7B j1vQ== 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=jsCuKDj3FGT/WnrFpPRt7qNP3KY7XvvvTOze3Gs9AR4=; b=W3W3AhBLHERL+NDCSV+IkZjbsladz3w+zlt/zszTH2vYnvQGnIVMb1+CoPvsBHvax4 /R8vyw7xACa6eSWLDVDJNlzphx4eRf2Xzxr7RP12cYnma1fIGA38mSV1pZTN0Xu54CdE DdqeAggO5eLflxVeiKVjyDqmjXPZeyErPILAUuxG/Rz1/NEXkC1wCY2/nETymOHDmEBv BKRsyfZh1bUVhIYDM8PXDVomThUzoWQvi8kTpguGYux2ycG+TCoNkD89YWvPFr6+DSmn lMZp3Sufm81AIi1D1oAx5WAAcJW4JQAbs6Kab9lPDkZ8btJDOPVMmHusplXZ28fBOqdX ID2A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10-v6si5550849pgc.261.2018.07.19.06.15.02; Thu, 19 Jul 2018 06:15:17 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731767AbeGSN5U (ORCPT + 99 others); Thu, 19 Jul 2018 09:57:20 -0400 Received: from mga01.intel.com ([192.55.52.88]:63075 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731532AbeGSN5T (ORCPT ); Thu, 19 Jul 2018 09:57:19 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 06:14:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,374,1526367600"; d="scan'208";a="76092498" Received: from sandybridge-desktop.sh.intel.com (HELO sandybridge-desktop) ([10.239.160.116]) by orsmga002.jf.intel.com with ESMTP; 19 Jul 2018 06:14:10 -0700 Date: Thu, 19 Jul 2018 21:20:03 +0800 From: Yu Chen To: Pavel Machek Cc: "Rafael J . Wysocki" , Eric Biggers , "Lee, Chun-Yi" , Theodore Ts o , Stephan Mueller , Denis Kenzior , linux-pm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, "Gu, Kookoo" , "Zhang, Rui" Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption Message-ID: <20180719132003.GA30981@sandybridge-desktop> References: <20180718202235.GA4132@amd> <20180718235851.GA22170@sandybridge-desktop> <20180719110149.GA4679@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180719110149.GA4679@amd> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 19, 2018 at 01:01:49PM +0200, Pavel Machek wrote: > On Thu 2018-07-19 07:58:51, Yu Chen wrote: > > Hi, > > On Wed, Jul 18, 2018 at 10:22:35PM +0200, Pavel Machek wrote: > > > On Thu 2018-07-19 00:38:06, Chen Yu wrote: > > > > As security becomes more and more important, we add the in-kernel > > > > encryption support for hibernation. > > > > > > Sorry, this does not really explain what security benefit it is > > > supposed have to against what attack scenarios. > > > > > > Which unfortunately means it can not reviewed. > > > > > > Note that uswsusp already provides encryption. If this is supposed to > > > have advantages over it, please say so. > > > > > The advantages are described in detail in > > [PATCH 1/4]'s log, please refer to that. > > Are you refering to this? > Not this one. I've sent v2 of this patch set which explain more on this: https://patchwork.kernel.org/patch/10532935/ Let me paste the log here: 1. (This is not to compare with uswsusp but other tools) One advantage is: Users do not have to encrypt the whole swap partition as other tools. 2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages: 2.1 Not having to transfer plain text kernel memory to user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/ linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to: "There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data." https://patchwork.kernel.org/patch/10476751/ 2.2 Not having to copy each page to user space one by one not in parallel, which might introduce significant amount of copy_to_user() and it might not be efficient on servers having large amount of DRAM. 2.3 Distribution has requirement to do snapshot signature for verification, which can be built by leveraging this patch set. 2.4 The encryption is in the kernel, so it doesn't have to worry too much about bugs in user space utilities and similar, for example. > # Generally the advantage is: Users do not have to > # encrypt the whole swap partition as other tools. > # After all, ideally kernel memory should be encrypted > # by the kernel itself. > > Sorry, this does not really explain what security benefit it is > supposed have to against what attack scenarios. > > Note that uswsusp already provides encryption. If this is supposed to > have advantages over it, please say so. > > Also note that joeyli has patch series which encrypts > both in-kernel and uswsusp hibernation methods. His motivation is > secure boot. How does this compare to his work? > Joey Lee and I had a discussion on his previous work at https://patchwork.kernel.org/patch/10476751 We collaborate on this task and his snapshot signature feature can be based on this patch set. Thanks, Yu