Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753059AbdC3Bud (ORCPT ); Wed, 29 Mar 2017 21:50:33 -0400 Received: from mail-it0-f51.google.com ([209.85.214.51]:37581 "EHLO mail-it0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbdC3Bub (ORCPT ); Wed, 29 Mar 2017 21:50:31 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170329203908.GA39222@beast> <94D018AF-07C3-47BE-9C62-4B2923D3E39B@zytor.com> From: Kees Cook Date: Wed, 29 Mar 2017 18:50:29 -0700 X-Google-Sender-Auth: R_l7xCNYsbx2VBRGq_Usdt1yRzo Message-ID: Subject: Re: [PATCH] x86/fpu: move FPU state into separate cache To: Linus Torvalds Cc: Peter Anvin , Andy Lutomirski , LKML , Rik van Riel , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "x86@kernel.org" , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , 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 , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3072 Lines: 82 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 -- Kees Cook Pixel Security