From: Pavel Machek <pavel@denx.de>
To: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@kernel.org>, James Morse <james.morse@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Matt Redfearn <matt.redfearn@imgtec.com>,
Yves-Alexis Perez <corsac@debian.org>,
Emrah Demir <ed@abdsec.com>, Jonathan Corbet <corbet@lwn.net>,
"x86@kernel.org" <x86@kernel.org>,
Len Brown <len.brown@intel.com>, Borislav Petkov <bp@suse.de>,
Andy Lutomirski <luto@kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation
Date: Fri, 15 Apr 2016 15:06:26 +0200 [thread overview]
Message-ID: <20160415130626.GA21457@amd> (raw)
In-Reply-To: <CAGXu5j+cTYF_OGG=u4BKU5X3f6TF0FdAcES9e_8S0ajMyjhn6Q@mail.gmail.com>
Hi!
> > Now I notice that it is quite unclear if it actually changes
> > anything...
>
> Okay, right. So, there are a few problems that this patch is solving,
> and maybe it needs to be broken up into separate patches, but it
> didn't seem like it to me at the time. Specifically:
>
> 1) The x86 hibernation and KASLR code don't play well together currently.
>
> "1" was worked around so that both could be built in, but only one
> would be active at a time. This lead to:
> 2) The general hibernation code contains kernel arguments that should
> only affect x86.
>
> And we have the desire by folks to have KASLR enabled by default on
> x86, giving us:
>
> 3) There is no build-time way on x86 to switch the preference of KASLR
> vs hibernation.
>
> I think "2" should be solved for this release, since arm64 KASLR is
> landing, and mistakenly booting an arm64 system with "kaslr" on the
> command line will needlessly disable hibernation.
Yes, I have no problem with "2".
> 3 and 2 are a result of 1, and IIUC, you're saying you want to solve 1
> to make everything else go away? My only concern with that idea is
> that I don't (yet) have the knowledge of x86 hibernation internals to
> fix this, and it'll take a while to get to having KASLR on by default
> if we have to wait on me to fix hibernation. (I'm not saying I
> won't/can't, it's just that it'll take me time to come up to speed on
> it.)
>
> That do you think?
I believe it is more important to get it right than to have a solution
right now. x86-64 should be best architecture to start...
I don't understand kaslr, but it looks to me like you need to store
the kaslr seed in the hibernation image, then use thet in
set_up_temporary_mappings(). It should not be that bad.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@denx.de>
To: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@kernel.org>, James Morse <james.morse@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Matt Redfearn <matt.redfearn@imgtec.com>,
Yves-Alexis Perez <corsac@debian.org>,
Emrah Demir <ed@abdsec.com>, Jonathan Corbet <corbet@lwn.net>,
"x86@kernel.org" <x86@kernel.org>,
Len Brown <len.brown@intel.com>, Borislav Petkov <bp@suse.de>,
Andy Lutomirski <luto@kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation
Date: Fri, 15 Apr 2016 15:06:26 +0200 [thread overview]
Message-ID: <20160415130626.GA21457@amd> (raw)
In-Reply-To: <CAGXu5j+cTYF_OGG=u4BKU5X3f6TF0FdAcES9e_8S0ajMyjhn6Q@mail.gmail.com>
Hi!
> > Now I notice that it is quite unclear if it actually changes
> > anything...
>
> Okay, right. So, there are a few problems that this patch is solving,
> and maybe it needs to be broken up into separate patches, but it
> didn't seem like it to me at the time. Specifically:
>
> 1) The x86 hibernation and KASLR code don't play well together currently.
>
> "1" was worked around so that both could be built in, but only one
> would be active at a time. This lead to:
> 2) The general hibernation code contains kernel arguments that should
> only affect x86.
>
> And we have the desire by folks to have KASLR enabled by default on
> x86, giving us:
>
> 3) There is no build-time way on x86 to switch the preference of KASLR
> vs hibernation.
>
> I think "2" should be solved for this release, since arm64 KASLR is
> landing, and mistakenly booting an arm64 system with "kaslr" on the
> command line will needlessly disable hibernation.
Yes, I have no problem with "2".
> 3 and 2 are a result of 1, and IIUC, you're saying you want to solve 1
> to make everything else go away? My only concern with that idea is
> that I don't (yet) have the knowledge of x86 hibernation internals to
> fix this, and it'll take a while to get to having KASLR on by default
> if we have to wait on me to fix hibernation. (I'm not saying I
> won't/can't, it's just that it'll take me time to come up to speed on
> it.)
>
> That do you think?
I believe it is more important to get it right than to have a solution
right now. x86-64 should be best architecture to start...
I don't understand kaslr, but it looks to me like you need to store
the kaslr seed in the hibernation image, then use thet in
set_up_temporary_mappings(). It should not be that bad.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2016-04-15 13:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 22:16 [kernel-hardening] [PATCH v2] kaslr: allow kASLR to be default over Hibernation Kees Cook
2016-04-12 22:16 ` Kees Cook
2016-04-14 20:01 ` [kernel-hardening] " Pavel Machek
2016-04-14 20:01 ` Pavel Machek
2016-04-14 20:14 ` [kernel-hardening] " Kees Cook
2016-04-14 20:14 ` Kees Cook
2016-04-14 20:34 ` [kernel-hardening] " Pavel Machek
2016-04-14 20:34 ` Pavel Machek
2016-04-14 22:42 ` [kernel-hardening] " Kees Cook
2016-04-14 22:42 ` Kees Cook
2016-04-15 9:20 ` [kernel-hardening] " Ingo Molnar
2016-04-15 9:20 ` Ingo Molnar
2016-04-15 13:06 ` Pavel Machek [this message]
2016-04-15 13:06 ` Pavel Machek
2016-04-15 16:25 ` [kernel-hardening] " Emrah Demir
2016-04-15 16:25 ` Emrah Demir
2016-04-16 19:58 ` [kernel-hardening] " Pavel Machek
2016-04-16 19:58 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160415130626.GA21457@amd \
--to=pavel@denx.de \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@suse.de \
--cc=corbet@lwn.net \
--cc=corsac@debian.org \
--cc=ed@abdsec.com \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=len.brown@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=matt.redfearn@imgtec.com \
--cc=mingo@kernel.org \
--cc=rafael@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.