[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1532590246.7411.3.camel@suse.com>
Date: Thu, 26 Jul 2018 09:30:46 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Yu Chen <yu.c.chen@...el.com>
Cc: Pavel Machek <pavel@....cz>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Eric Biggers <ebiggers@...gle.com>,
"Lee, Chun-Yi" <jlee@...e.com>, Theodore Ts o <tytso@....edu>,
Stephan Mueller <smueller@...onox.de>,
Denis Kenzior <denkenz@...il.com>, linux-pm@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
"Gu, Kookoo" <kookoo.gu@...el.com>,
"Zhang, Rui" <rui.zhang@...el.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation
encryption
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
Powered by blists - more mailing lists