linux-kernel - Re: [PATCH 0/2] make kASLR vs hibernation boot-time selectable

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAGXu5jKanRjK66P9dFYctXfQxT+da_9z8vqy8s+WqgW1cw17-Q@mail.gmail.com>
Date:	Thu, 12 Jun 2014 13:58:00 -0700
From:	Kees Cook <keescook@...omium.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Wei Yongjun <yongjun_wei@...ndmicro.com.cn>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/2] make kASLR vs hibernation boot-time selectable

On Thu, Jun 12, 2014 at 1:29 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 06/12/2014 01:27 PM, Kees Cook wrote:
>>>
>>> Any way we can make them work together instead?
>>
>> I'm sure there is, but I don't know the solution. :)
>>
>> At the very least this gets us one step closer (we can build them together).
>>
>
> But it is really invasive.

Well, I don't agree there. I actually would like to be able to turn
off hibernation support on distro kernels regardless of kASLR, so I
think this is really killing two birds with one stone.

> I have to admit to being somewhat fuzzy on what the core problem with
> hibernation and kASLR is... in both cases there is a set of pages that
> need to be installed, some of which will overlap the loader kernel.
> What am I missing?

I don't know how resume works, but I have assumed that the newly
loaded kernel stays in memory and pulls in the vmalloc, kmalloc,
modules, and userspace memory maps from disk. Since these things can
easily contain references to kernel text, if the newly loaded kernel
has moved with regard to the hibernated image, everything breaks.
IIUC, this is similar why you can't rebuild your kernel and resume
from a different version.

Potential solutions might be to do some kind of kexec-ish second
kernel load that puts it in the "right" place, based on what's stored
in the on-disk image. It sounds extremely non-trivial, and isn't
something I will have time to work on in the foreseeable future.

Making them both build together, however, that I can do. :)

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/