Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp148045imm; Thu, 26 Jul 2018 00:40:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdYypDM5NdY4MeawKselzaUUDc1lrmZYpSuRE/xx+O2eUJbHSN+E7Nn+IjyUeV6Z39V3D+/ X-Received: by 2002:a62:6d02:: with SMTP id i2-v6mr980439pfc.218.1532590825271; Thu, 26 Jul 2018 00:40:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532590825; cv=none; d=google.com; s=arc-20160816; b=efjITqjyHHgjiN+0FiA0k/Hj7r82sFqC80y+Th36+wI6mACxEASdtHRnagFboMO7LW XPO1N9wRWI6qmtgKx+iHfFpQIEPUTxjRzC7FcbwWpar3QFAy+EzJLZz+r3NAc8zwlVQR 4qM7PL8zkz0wfzZqxMK8iPQh9LoQYjV0loWq6dc3h0yoXffQAO3Y5VtYUW2l8IBegM/q i25R6V285hpp0punzN5Aylas+Zwc1i02PjGPk0iIlXsVlmPzv9jf8xz9lu0nbXzULMxT jvRhGXHg9g3So66TFOC0Ws47pZ4TTWm8FYw09J7yUwchVZ8Ob6SAFE9dlG+nHk2yGa8B v/dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=QoCiChveRfOz6XuJX/JvvpnExbWbqhUYym69UtO7XZE=; b=Wmv9lV9w4rUKLS9HXO8RA3E4ZIvEc/Hij8Kw6HqRHhkTvh6sy0MooBstXDFhkg/PVg y0J4tRiNmfGt6nJF7XJp0/z6KMLq/qKUbbd2/RMwhM/mDUviTb/pCsQCTeYmR4bn+1V5 OigFbnM2gd+mlFV3g0grrixrj1IpGssazh3a0JY7oLX12JHe2Bzf3hDXYP1TeekdnfD9 2nV5xQapKSJjgtr768Tq9DrhcY23jT5Wce6J5J/WxtQ4IrbrM7O7HXw2BtiEmgJy7HPc nAj/DawKPpHA2QmKgppi7nJH0y71K/NjQV3BgWmsfTFMlFMhIfhLgnLrb99K8UEEfQcv nGoQ== 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 k184-v6si658179pge.209.2018.07.26.00.40.10; Thu, 26 Jul 2018 00:40:25 -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 S1729078AbeGZIyl (ORCPT + 99 others); Thu, 26 Jul 2018 04:54:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:44272 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728690AbeGZIyl (ORCPT ); Thu, 26 Jul 2018 04:54:41 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1A104AD83; Thu, 26 Jul 2018 07:39:06 +0000 (UTC) Message-ID: <1532590246.7411.3.camel@suse.com> Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation encryption From: Oliver Neukum To: Yu Chen Cc: Pavel Machek , "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" Date: Thu, 26 Jul 2018 09:30:46 +0200 In-Reply-To: <20180723162302.GA4503@sandybridge-desktop> References: <20180718202235.GA4132@amd> <20180718235851.GA22170@sandybridge-desktop> <20180719110149.GA4679@amd> <20180719132003.GA30981@sandybridge-desktop> <20180720102532.GA20284@amd> <1532346156.3057.11.camel@suse.com> <20180723162302.GA4503@sandybridge-desktop> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Di, 2018-07-24 at 00:23 +0800, Yu Chen wrote: > > Good point, we once tried to generate key in kernel, but people > suggest to generate key in userspace and provide it to the > kernel, which is what ecryptfs do currently, so it seems this > should also be safe for encryption in kernel. > https://www.spinics.net/lists/linux-crypto/msg33145.html > Thus Chun-Yi's signature can use EFI key and both the key from > user space. Hi, ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space. I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis? Regards Oliver