On Wed, Mar 29, 2017 at 2:30 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Wed, Mar 29, 2017 at 2:09 PM, Kees Cook <keesc...@chromium.org> wrote: >> >> They're adjacent already, which poses a problem for the struct layout >> randomization plugin, since adjacency may no longer be true (after >> layout randomization). T > > What? > > The layout randomization can't change anything, if you just make the > adjacency be done explicitly instead of by having the thing be a fixed > member. > > 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. If it does, the gcc plugin is > such unbelievable garbage that it would be insane to depend on such > shit in the first place. >
Randomization also needs to leave thread_info at the beginning. Can it do that?
