[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Mar 2017 18:50:29 -0700
From: Kees Cook <keescook@...omium.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Anvin <hpa@...or.com>, Andy Lutomirski <luto@...capital.net>,
LKML <linux-kernel@...r.kernel.org>, Rik van Riel <riel@...hat.com>,
Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, Dave Hansen <dave.hansen@...ux.intel.com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>, Masahiro Yamada <yamada.masahiro@...ionext.com>,
Borislav Petkov <bp@...e.de>, Christian Borntraeger <borntraeger@...ibm.com>,
Thomas Garnier <thgarnie@...gle.com>, Brian Gerst <brgerst@...il.com>,
He Chen <he.chen@...ux.intel.com>, Mathias Krause <minipli@...glemail.com>,
Fenghua Yu <fenghua.yu@...el.com>, Piotr Luc <piotr.luc@...el.com>, Kyle Huey <me@...ehuey.com>,
Len Brown <len.brown@...el.com>, KVM <kvm@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] x86/fpu: move FPU state into separate cache
On Wed, Mar 29, 2017 at 4:56 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Mar 29, 2017 at 3:28 PM, <hpa@...or.com> wrote:
>> On March 29, 2017 2:41:00 PM PDT, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>>
>> An alternative is to wrap the randomized structure inside a nonrandomized wrapper structure.
>
> That's probably a reasonable alternative. Making "struct task_struct"
> be something that contains a fixed beginning and end, and just have an
> unnamed randomized part in the middle might be the way to go.
That could work. I'll play around with it.
(And to answer from earlier in the thread: yes the plugin handles
trailing "char foo[]" stuff, etc.)
> Something like
>
> struct task_struct {
> struct thread_info thread_info;
>
> /* Critical scheduling state goes here */
> /* .. keep it all in one cacheline */
>
> struct randomized_task_struct {
> this is where the "I don't care" stuff goes..
> };
>
> /* CPU-specific state of this task: */
> struct thread_struct thread;
>
> /*
> * WARNING: on x86, 'thread_struct' contains a variable-sized
> * structure. It *MUST* be at the end of 'task_struct'.
> *
> * Do not put anything below here!
> */
> };
>
> would randomize the bulk of it but leave some core stuff at fixed places.
>
> Note that the whole concept of randomized structure member ordering is
> largely security theater. It makes different distributions have
> different offsets, but practically speaking
Distros, yes, it's just another factor the attack has to look up. For
internally/locally built kernels, though, it becomes an interesting
problem for an attack.
> (a) you'll be able to match up offsets with "uname -r", so it's a
> slight inconvenience and mostly useless for big distros that would be
> common targets (or common IoT targets or whatever)
>
> (b) any distro that supports some binary modules (which includes a
> lot of Android stuff, for example) will have serious problems and
> likely turn it off
Ironically, solving "b" for the distro makes solving "a" for the
attacker easier: the random seed is already part of the build output,
so third-party modules can be built against it with the plugin too.
(FWIW, very few Android devices use modular kernels.)
> so it's imnsho a pretty questionable security thing. It's likely most
> useful for one-off "special secure installations" than mass
> productions.
Well, Facebook and Google don't publish their kernel builds. :)
> So I seriously believe that it's useful mainly *only* if it's really
> simple and convenient (for both distributions and developers), and
> once we have to play games to work around it, I think that's a strong
> signal that we shouldn't bother.
Agreed: that's why I'm trying to see what's actually reasonable to do
here. I think randomizing task_struct is still possible. (There are a
few tricky structs, but for most stuff It Just Works.)
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
