Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Mar 2017 18:50:29 -0700
From: Kees Cook <>
To: Linus Torvalds <>
Cc: Peter Anvin <>, Andy Lutomirski <>, 
	LKML <>, Rik van Riel <>, 
	Andy Lutomirski <>, Thomas Gleixner <>, Ingo Molnar <>, 
	"" <>, Paolo Bonzini <>, 
	Radim Krčmář <>, 
	Peter Zijlstra <>, Dave Hansen <>, 
	Yu-cheng Yu <>, Masahiro Yamada <>, 
	Borislav Petkov <>, Christian Borntraeger <>, 
	Thomas Garnier <>, Brian Gerst <>, 
	He Chen <>, Mathias Krause <>, 
	Fenghua Yu <>, Piotr Luc <>, Kyle Huey <>, 
	Len Brown <>, KVM <>, 
	"" <>
Subject: Re: [PATCH] x86/fpu: move FPU state into separate cache

On Wed, Mar 29, 2017 at 4:56 PM, Linus Torvalds
<> wrote:
> On Wed, Mar 29, 2017 at 3:28 PM,  <> wrote:
>> On March 29, 2017 2:41:00 PM PDT, Linus Torvalds <> 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 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.