Re: [PATCH] x86/fpu: move FPU state into separate cache

[Linus Torvalds]

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

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

 (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

so it's imnsho a pretty questionable security thing. It's likely most
useful for one-off "special secure installations" than mass
productions.

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.

                      Linus