Hi Kees,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.11-rc4 next-20170330]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kees-Cook/x86-
Hi Kees,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.11-rc4 next-20170330]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kees-Cook/x86-
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
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 contai
On March 29, 2017 2:41:00 PM PDT, Linus Torvalds
wrote:
>On Wed, Mar 29, 2017 at 2:35 PM, Andy Lutomirski
>wrote:
>>
>> Randomization also needs to leave thread_info at the beginning. Can
>it do that?
>
>Good point, and good question. No idea if the gcc extension can do,
>but yes, it clearly ne
On Wed, Mar 29, 2017 at 2:35 PM, Andy Lutomirski wrote:
>
> Randomization also needs to leave thread_info at the beginning. Can it do
> that?
Good point, and good question. No idea if the gcc extension can do,
but yes, it clearly needs a "you can't move this entry".
I assume it has some such c
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 r
On Wed, Mar 29, 2017 at 2:30 PM, Linus Torvalds
wrote:
> On Wed, Mar 29, 2017 at 2:09 PM, Kees Cook 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?
>
> Th
On Wed, Mar 29, 2017 at 2:09 PM, Kees Cook 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
a
On 03/29/2017 02:09 PM, Kees Cook 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). This adjacency (or not) isn't really the
> problem: it's that FPU state size is only known a
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
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
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_st
13 matches
Mail list logo
