Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Mar 2017 14:35:57 -0700
From: Linus Torvalds <>
To: Kees Cook <>
Cc: "H. Peter Anvin" <>, LKML <>, 
	Rik van Riel <>, Andy Lutomirski <>, Thomas Gleixner <>, 
	Ingo Molnar <>, "" <>, Paolo Bonzini <>, 
	Radim Krčmář <>, 
	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 <>, 
	"" <>
Subject: Re: [PATCH] x86/fpu: move FPU state into separate cache

On Wed, Mar 29, 2017 at 2:30 PM, Linus Torvalds
<> wrote:
> The trivial model might be to just declare the fpu part as an unsized
> array at the end:
>         /* Floating point and extended processor state */
>         struct fpu              fpu[];
> because there is no way in hell that any randomization code can move
> those kinds of unsized arrays around.

Side note: that approach would seem to have the added advantage that
because "fpu" now is an array, it syntactically acts like a pointer in
C, so now syntactically it's going to be equivalent to having a
"struct fpu *" pointer element, but from an allocation and code
generation standpoint it all is like allocating the fpu structure
together with the task struct.


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.