linux-kernel - Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180625115913.GD17001@amd>
Date:   Mon, 25 Jun 2018 13:59:13 +0200
From:   Pavel Machek <pavel@....cz>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Chen Yu <yu.c.chen@...el.com>, Len Brown <len.brown@...el.com>,
        "Lee, Chun-Yi" <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption



> > Well, AFAICT in this case userland has the key and encrypted data are
> > on disk. That does not seem to be improvement.
> 
> Not really.
> 
> With the encryption in the kernel, if the kernel is careful enough,
> use space will not be able to read the image even if it knows the
> passphrase, unless it can also add itself to the initramfs image
> loaded by the restore kernel, which (at least) can be made way more
> difficult than simply reading the plain-text image data via an I/F
> readily provided by the kernel.

I still do not see the improvement. If you are root, you can modify
the initramfs and decrypt the data.

Please explain in the changelog how this is better than existing solution.

> >> Besides, the user space part of what you are calling uswsusp has not
> >> been actively maintained for years now and honestly I don't know how
> >> many users of it there are.
> >
> > I'd assume distros want progress bars so they still use it?
> 
> I'd rather not speak for distros, but if hibernation images are
> written to fast storage, progress bars are not that useful any more.
> They are not used on Windows any more, for one.
> 
> > Anyway, there's solution for encrypted hibernation.
> 
> Which is suboptimal and you know it.

If this is better, please explain how in the changelog.

> > If Intel wants to invent different solution for that, and put it into kernel, they
> > should explain what the advantages are, relative to existing solution.
> 
> I'm not sure what "they" is supposed to mean here, but the advantages
> are quite clear to me: better security and reduced syscall overhead.

Better security against which attack?

Syscall overhead is not a problem for hibernation, and you know it.

		    	  	      		       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)