On Mon, Nov 5, 2018 at 9:20 AM Dave Hansen wrote:
>
>
> On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> > I should add: if this patch is *not* applied, then I think we'll
> > need to replace the sw_error_code check with user_mode(regs) to avoid
> > an info leak if CET is enabled. Because, with CET,
On Mon, Nov 5, 2018 at 9:20 AM Dave Hansen wrote:
>
>
> On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> > I should add: if this patch is *not* applied, then I think we'll
> > need to replace the sw_error_code check with user_mode(regs) to avoid
> > an info leak if CET is enabled. Because, with CET,
On 11/5/18 8:27 AM, Waiman Long wrote:
> So gcc had changed to avoid doing that, but my main concern are old
> binaries that were compiled with old gcc.
Yeah, fair enough.
FWIW, I don't have any strong feelings about this patch either way, but
supporting old binaries/compilers without crashing
On 11/5/18 8:27 AM, Waiman Long wrote:
> So gcc had changed to avoid doing that, but my main concern are old
> binaries that were compiled with old gcc.
Yeah, fair enough.
FWIW, I don't have any strong feelings about this patch either way, but
supporting old binaries/compilers without crashing
On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> I should add: if this patch is *not* applied, then I think we'll
> need to replace the sw_error_code check with user_mode(regs) to avoid
> an info leak if CET is enabled. Because, with CET, WRUSS will allow
> a *kernel* mode access (where regs->sp is
On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> I should add: if this patch is *not* applied, then I think we'll
> need to replace the sw_error_code check with user_mode(regs) to avoid
> an info leak if CET is enabled. Because, with CET, WRUSS will allow
> a *kernel* mode access (where regs->sp is
On 11/02/2018 06:28 PM, Dave Hansen wrote:
> On 11/2/18 12:50 PM, Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack() decide if a
On 11/02/2018 06:28 PM, Dave Hansen wrote:
> On 11/2/18 12:50 PM, Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack() decide if a
On Sun, Nov 4, 2018 at 9:11 PM Andy Lutomirski wrote:
>
> On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen wrote:
> >
> > On 11/2/18 12:50 PM, Waiman Long wrote:
> > > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > >> On 11/2/18 12:40 PM, Waiman Long wrote:
> > >>> The 64k+ limit check is kind of
On Sun, Nov 4, 2018 at 9:11 PM Andy Lutomirski wrote:
>
> On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen wrote:
> >
> > On 11/2/18 12:50 PM, Waiman Long wrote:
> > > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > >> On 11/2/18 12:40 PM, Waiman Long wrote:
> > >>> The 64k+ limit check is kind of
On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen wrote:
>
> On 11/2/18 12:50 PM, Waiman Long wrote:
> > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> >> On 11/2/18 12:40 PM, Waiman Long wrote:
> >>> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >>> to just let expand_stack()
On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen wrote:
>
> On 11/2/18 12:50 PM, Waiman Long wrote:
> > On 11/02/2018 03:44 PM, Dave Hansen wrote:
> >> On 11/2/18 12:40 PM, Waiman Long wrote:
> >>> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >>> to just let expand_stack()
On 11/2/18 12:50 PM, Waiman Long wrote:
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>> to just let expand_stack() decide if a segmentation fault should happen.
>> With the 64k
On 11/2/18 12:50 PM, Waiman Long wrote:
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>> On 11/2/18 12:40 PM, Waiman Long wrote:
>>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>>> to just let expand_stack() decide if a segmentation fault should happen.
>> With the 64k
On 11/02/2018 04:11 PM, Andy Lutomirski wrote:
> On Fri, Nov 2, 2018 at 12:50 PM Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack()
On 11/02/2018 04:11 PM, Andy Lutomirski wrote:
> On Fri, Nov 2, 2018 at 12:50 PM Waiman Long wrote:
>> On 11/02/2018 03:44 PM, Dave Hansen wrote:
>>> On 11/2/18 12:40 PM, Waiman Long wrote:
The 64k+ limit check is kind of arbitrary. So the check is now removed
to just let expand_stack()
On Fri, Nov 2, 2018 at 12:50 PM Waiman Long wrote:
>
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > On 11/2/18 12:40 PM, Waiman Long wrote:
> >> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >> to just let expand_stack() decide if a segmentation fault should happen.
>
On Fri, Nov 2, 2018 at 12:50 PM Waiman Long wrote:
>
> On 11/02/2018 03:44 PM, Dave Hansen wrote:
> > On 11/2/18 12:40 PM, Waiman Long wrote:
> >> The 64k+ limit check is kind of arbitrary. So the check is now removed
> >> to just let expand_stack() decide if a segmentation fault should happen.
>
On 11/02/2018 03:44 PM, Dave Hansen wrote:
> On 11/2/18 12:40 PM, Waiman Long wrote:
>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>> to just let expand_stack() decide if a segmentation fault should happen.
> With the 64k check removed, what's the next limit that we
On 11/02/2018 03:44 PM, Dave Hansen wrote:
> On 11/2/18 12:40 PM, Waiman Long wrote:
>> The 64k+ limit check is kind of arbitrary. So the check is now removed
>> to just let expand_stack() decide if a segmentation fault should happen.
> With the 64k check removed, what's the next limit that we
On 11/2/18 12:40 PM, Waiman Long wrote:
> The 64k+ limit check is kind of arbitrary. So the check is now removed
> to just let expand_stack() decide if a segmentation fault should happen.
With the 64k check removed, what's the next limit that we bump into? Is
it just the stack_guard_gap space
On 11/2/18 12:40 PM, Waiman Long wrote:
> The 64k+ limit check is kind of arbitrary. So the check is now removed
> to just let expand_stack() decide if a segmentation fault should happen.
With the 64k check removed, what's the next limit that we bump into? Is
it just the stack_guard_gap space
The current x86 page fault handler allows stack access below the stack
pointer if it is no more than 64k+256 bytes. Any access beyond the 64k+
limit will cause a segmentation fault.
The gcc -fstack-check option generates code to probe the stack for
large stack allocation to see if the stack is
The current x86 page fault handler allows stack access below the stack
pointer if it is no more than 64k+256 bytes. Any access beyond the 64k+
limit will cause a segmentation fault.
The gcc -fstack-check option generates code to probe the stack for
large stack allocation to see if the stack is
24 matches
Mail list logo
