Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: > On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: >> * Daniel Micay: >> >> > -fstack-stack is supposed to handle a single guard by default, and >> > that's all there is for thread stacks by default. >> >> Okay, then I'll really have to look at the probing offsets again.

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: > On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: >> * Daniel Micay: >> >> > -fstack-stack is supposed to handle a single guard by default, and >> > that's all there is for thread stacks by default. >> >> Okay, then I'll really have to look at the probing offsets again.

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: > * Daniel Micay: > > > -fstack-stack is supposed to handle a single guard by default, and > > that's all there is for thread stacks by default. > > Okay, then I'll really have to look at the probing offsets again. > It's been on my to-do

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote: > * Daniel Micay: > > > -fstack-stack is supposed to handle a single guard by default, and > > that's all there is for thread stacks by default. > > Okay, then I'll really have to look at the probing offsets again. > It's been on my to-do

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: > -fstack-stack is supposed to handle a single guard by default, and > that's all there is for thread stacks by default. Okay, then I'll really have to look at the probing offsets again. It's been on my to-do list since about 2012, and arguably, it *is* a user-space thing. And I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: > -fstack-stack is supposed to handle a single guard by default, and > that's all there is for thread stacks by default. Okay, then I'll really have to look at the probing offsets again. It's been on my to-do list since about 2012, and arguably, it *is* a user-space thing. And I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Jann Horn: > Until recently: Zero, no guard pages below stacks, stack overflow > goes straight into some other allocation. > Now: One guard page, thanks to a lot of work by Andy Lutomirski. > (I think that change is in the current 4.9-rc3 kernel, but not in > any stable kernel yet.) Sorry, I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Jann Horn: > Until recently: Zero, no guard pages below stacks, stack overflow > goes straight into some other allocation. > Now: One guard page, thanks to a lot of work by Andy Lutomirski. > (I think that change is in the current 4.9-rc3 kernel, but not in > any stable kernel yet.) Sorry, I

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:22 +0100, Jann Horn wrote: > On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote: > > * Daniel Micay: > > > > > > It makes a lot of sense on x86_64 where it means the canary is > > > > still 56 bits. Also, you want -fstack-check for protecting again > > > >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:22 +0100, Jann Horn wrote: > On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote: > > * Daniel Micay: > > > > > > It makes a lot of sense on x86_64 where it means the canary is > > > > still 56 bits. Also, you want -fstack-check for protecting again > > > >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote: > * Daniel Micay: > > >> It makes a lot of sense on x86_64 where it means the canary is > >> still 56 bits. Also, you want -fstack-check for protecting again > >> stack overflows rather than stack *buffer* overflow. SSP won't > >>

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote: > * Daniel Micay: > > >> It makes a lot of sense on x86_64 where it means the canary is > >> still 56 bits. Also, you want -fstack-check for protecting again > >> stack overflows rather than stack *buffer* overflow. SSP won't > >>

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:10 +0100, Florian Weimer wrote: > * Daniel Micay: >  > > > It makes a lot of sense on x86_64 where it means the canary is > > > still 56 bits. Also, you want -fstack-check for protecting again > > > stack overflows rather than stack *buffer* overflow. SSP won't > > >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 22:10 +0100, Florian Weimer wrote: > * Daniel Micay: >  > > > It makes a lot of sense on x86_64 where it means the canary is > > > still 56 bits. Also, you want -fstack-check for protecting again > > > stack overflows rather than stack *buffer* overflow. SSP won't > > >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: >> It makes a lot of sense on x86_64 where it means the canary is >> still 56 bits. Also, you want -fstack-check for protecting again >> stack overflows rather than stack *buffer* overflow. SSP won't >> really help you in that regard. Sadly, while -fstack-check now >> works well

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Daniel Micay: >> It makes a lot of sense on x86_64 where it means the canary is >> still 56 bits. Also, you want -fstack-check for protecting again >> stack overflows rather than stack *buffer* overflow. SSP won't >> really help you in that regard. Sadly, while -fstack-check now >> works well

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
> It makes a lot of sense on x86_64 where it means the canary is still > 56 > bits. Also, you want -fstack-check for protecting again stack > overflows > rather than stack *buffer* overflow. SSP won't really help you in that > regard. Sadly, while -fstack-check now works well in GCC 6 with little

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
> It makes a lot of sense on x86_64 where it means the canary is still > 56 > bits. Also, you want -fstack-check for protecting again stack > overflows > rather than stack *buffer* overflow. SSP won't really help you in that > regard. Sadly, while -fstack-check now works well in GCC 6 with little

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 21:45 +0100, Florian Weimer wrote: > * Jann Horn: > > > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > > > On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > > > > On machines with sizeof(unsigned long)==8, this ensures that the > > > > more >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Daniel Micay
On Mon, 2016-10-31 at 21:45 +0100, Florian Weimer wrote: > * Jann Horn: > > > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > > > On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > > > > On machines with sizeof(unsigned long)==8, this ensures that the > > > > more > > > >

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 09:45:59PM +0100, Florian Weimer wrote: > * Jann Horn: > > > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > >> > On machines with sizeof(unsigned long)==8, this ensures that the more > >>

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 09:45:59PM +0100, Florian Weimer wrote: > * Jann Horn: > > > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > >> > On machines with sizeof(unsigned long)==8, this ensures that the more > >> > significant

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Jann Horn: > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: >> > On machines with sizeof(unsigned long)==8, this ensures that the more >> > significant 32 bits of stack_canary are random, too. >> > stack_canary is

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Florian Weimer
* Jann Horn: > On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: >> On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: >> > On machines with sizeof(unsigned long)==8, this ensures that the more >> > significant 32 bits of stack_canary are random, too. >> > stack_canary is defined as

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > > On machines with sizeof(unsigned long)==8, this ensures that the more > > significant 32 bits of stack_canary are random, too. > > stack_canary is defined as unsigned

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

2016-10-31 Thread Jann Horn
On Mon, Oct 31, 2016 at 09:04:02AM -0700, Kees Cook wrote: > On Mon, Oct 31, 2016 at 7:04 AM, Jann Horn wrote: > > On machines with sizeof(unsigned long)==8, this ensures that the more > > significant 32 bits of stack_canary are random, too. > > stack_canary is defined as unsigned long, all the