[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFx508viAhC_JqNnN0KvvoFDWrDZX3TXutDQRpdzWpegNw@mail.gmail.com>
Date: Wed, 29 Mar 2017 16:56:32 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Anvin <hpa@...or.com>
Cc: Andy Lutomirski <luto@...capital.net>, Kees Cook <keescook@...omium.org>,
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 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.
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
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.
