* 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.
* 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.
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
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
* 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
* 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
* 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
* 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
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
> > > >
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
> > > >
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
> >>
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
> >>
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
> > >
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
> > >
* 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
* 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
> 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
> 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
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
>
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
> > > >
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
> >>
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
* 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
* 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
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
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
26 matches
Mail list logo