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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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