[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1532437261.17797.22.camel@suse.com>
Date: Tue, 24 Jul 2018 15:01:01 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Pavel Machek <pavel@....cz>
Cc: Yu Chen <yu.c.chen@...el.com>,
"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 15:03 +0200, Pavel Machek wrote:
> On Tue 2018-07-24 14:47:54, Oliver Neukum wrote:
> > On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:
Hi,
> > > Safe against what kind of attack? Please describe what kind of
> > > security you are trying to provide.
> >
> > Unsigned code must not take over the priviledge level of signed code.
> > Hence:
> >
> > 1. Unsigned code must not allowed to read sensitive parts of signed
> > code's memory space
> >
> > 2. Unsigned code must not be able to alter the memory space of
> > signed code -> snapshots that are changed must not be able to be
> > resumed
>
> Ok.
>
> > > I don't think generating key in userspace is good enough for providing
> > > guarantees for secure-boot.
> >
> > Why?
>
> Because then, userpace has both key (now) and encrypted image (after
> reboot), so it can decrypt, modify, re-encrypt...?
Right. I was dense. But if the key is generated in kernel space,
the method works, doesn't it?
Regards
Oliver
Powered by blists - more mailing lists