[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180805100200.GB22948@amd>
Date: Sun, 5 Aug 2018 12:02:00 +0200
From: Pavel Machek <pavel@....cz>
To: Ryan Chen <yu.chen.surf@...il.com>
Cc: jlee@...e.com, Chen Yu <yu.c.chen@...el.com>, oneukum@...e.com,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
ebiggers@...gle.com, Theodore Ts'o <tytso@....edu>,
smueller@...onox.de, denkenz@...il.com,
Linux PM list <linux-pm@...r.kernel.org>,
linux-crypto@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
kookoo.gu@...el.com, Zhang Rui <rui.zhang@...el.com>
Subject: Re: [PATCH 0/4][RFC v2] Introduce the in-kernel hibernation
encryption
Hi!
> > User space doesn't need to involve. The EFI root key is generated by
> > EFI boot stub and be transfer to kernel. It's stored in EFI boot service
> > variable that it can only be accessed by trusted EFI binary when
> > secure boot is enabled.
> >
> Okay, this apply to the 'suspend' phase, right?
> I'm still a little confused about the 'resume' phase.
> Taking encryption as example(not signature),
> the purpose of doing hibernation encryption is to prevent other users
> from stealing ram content. Say, user A uses a passphrase to generate the
No, I don't think that's purpose here.
Purpose here is to prevent user from reading/modifying kernel memory
content on machine he owns.
Strange as it may sound, that is what "secure" boot requires (and what
Disney wants).
I guess it may have some non-evil uses,
too... https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists