Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

Pavel Machek
2019-01-07T18:07:07Z

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Hi!

> Thanks for your review!
>
> > > The hibernate function can be used to snapshot memory pages to an image,
> > > then kernel restores the image to memory space in a appropriate time.
> > > There have secrets in snapshot image and cracker may modifies it for
> > > hacking system. Encryption and authentication of snapshot image can protect
> > > the system.
> > >
> > > Hibernate function requests the master key through key retention service.
> > > The snapshot master key can be a trusted key or a user defined key. The
> > > name of snapshot master key is fixed to "swsusp-kmk". User should loads
> > > swsusp-kmk to kernel by keyctl tool before the hibernation resume.
> > > e.g. The swsusp-kmk must be loaded before systemd-hibernate-resume
> >
> > But if userspace has a key, encryption is useless against root.
> >
>
> Yes, but this concern is not only for hibernation encryption. This patch
> set does not provide solution against this concern.

So, can we postpone these patches until we have a solution secure
against root users?

> My security goals:
>
> - Encrypt and authicate hibernate snapshot image in kernel space. Userspace
> can only touch an encrypted and signed snapshot image.
>
> - The code of encryption are in kernel. They will be signed and verify with
> kernel binary when secure boot enabled. It's better than using
> unauthenticated userspace code at runtime.

These are not goals. I'd like to understand why you want to put it into
kernel in the first place.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]