Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933239AbdC2VLL (ORCPT ); Wed, 29 Mar 2017 17:11:11 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:35693 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932871AbdC2VJR (ORCPT ); Wed, 29 Mar 2017 17:09:17 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170329203908.GA39222@beast> From: Kees Cook Date: Wed, 29 Mar 2017 14:09:15 -0700 X-Google-Sender-Auth: nPdzyRcU2g2Jfa6ZQhQbMLpcUHU Message-ID: Subject: Re: [PATCH] x86/fpu: move FPU state into separate cache To: "H. Peter Anvin" Cc: 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: 1349 Lines: 31 On Wed, Mar 29, 2017 at 1:45 PM, H. Peter Anvin wrote: > On 03/29/17 13:39, Kees Cook wrote: >> This removes ARCH_WANTS_DYNAMIC_TASK_STRUCT from x86, leaving only s390 >> still defining this config. >> >> In order to support future structure layout randomization of the >> task_struct, none of the structure fields are allowed to have a specific >> position or dynamic size. To enable randomization of task_struct on >> x86, the FPU state must be moved to its own dynamically sized cache, >> and dereferenced from the task_struct. >> >> This change is nearly identical to what was done in grsecurity to support >> structure layout randomization. Hopefully I found all the needed changes. >> This passes allyesconfig, and boot tests. > > Is this really what we want to happen? It seems much more sane to > simply make them adjacent; they don't need to be part of the same > structure (in practice, there are three objects: thread_info, > task_struct, and the FPU state.) They're adjacent already, which poses a problem for the struct layout randomization plugin, since adjacency may no longer be true (after layout randomization). This adjacency (or not) isn't really the problem: it's that FPU state size is only known at runtime. Another solution would be to have FPU state be a fixed size... -Kees -- Kees Cook Pixel Security