* Jeff Law:
> On 06/28/2017 12:45 AM, Florian Weimer wrote:
>> * Richard Earnshaw:
>>
>>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt
>>> going on here. As Wilco points out, we can never defend against a
>>> function that is built without probe operations but skips t
On 06/28/2017 12:45 AM, Florian Weimer wrote:
> * Richard Earnshaw:
>
>> I can't help but feel there's a bit of a goode olde mediaeval witch hunt
>> going on here. As Wilco points out, we can never defend against a
>> function that is built without probe operations but skips the entire
>> guard z
* Richard Earnshaw:
> I can't help but feel there's a bit of a goode olde mediaeval witch hunt
> going on here. As Wilco points out, we can never defend against a
> function that is built without probe operations but skips the entire
> guard zone. The only defence there is a larger guard zone, b
Jeff Law wrote:
> You can be in one of 3 states when you start the callee's prologue.
>
> 1. You're somewhere in the normal stack.
>
> 2. You've past the guard and are already in the heap or elsewhere
>
> 3. You're somewhere in the guard
>
> State #3 is what we're trying to address. The attacker h
On 06/22/2017 10:07 AM, Szabolcs Nagy wrote:
> On 22/06/17 16:30, Jeff Law wrote:
>> It just happens to be the case that x86 hits *sp when it stores the
>> return pointer and that ppc always stores the backchain into *sp when it
>> allocates additional stack space. As a result on those targets we
On 06/21/2017 11:47 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>
>> I'm a little confused. I'm not defining or changing the ABI. I'm
>> working within my understanding of the existing aarch64 ABI used on
>> linux systems. My understanding after reading that ABI and the prologue
>> code for aar
On 22/06/17 16:30, Jeff Law wrote:
> It just happens to be the case that x86 hits *sp when it stores the
> return pointer and that ppc always stores the backchain into *sp when it
> allocates additional stack space. As a result on those targets we know
> the offset between the stack pointer and th
On 06/22/2017 03:53 AM, Richard Earnshaw (lists) wrote:
> On 21/06/17 18:25, Jeff Law wrote:
>> On 06/21/2017 02:41 AM, Richard Earnshaw (lists) wrote:
>>
But the stack pointer might have already been advanced into the guard
page by the caller. For the sake of argument assume the guard
On 21/06/17 18:25, Jeff Law wrote:
> On 06/21/2017 02:41 AM, Richard Earnshaw (lists) wrote:
>
>>> But the stack pointer might have already been advanced into the guard
>>> page by the caller. For the sake of argument assume the guard page is
>>> 0xf1000 and assume that our stack pointer at entr
On 06/20/2017 11:52 PM, Jeff Law wrote:
> I've also wondered if a 2 page guard would solve some of these problems.
> In the event of stack overflow, the kernel maps in one of the two pages
> for use by the signal handler. But changing things at this point may
> not be worth the effort.
I think
Jeff Law wrote:
> I'm a little confused. I'm not defining or changing the ABI. I'm
> working within my understanding of the existing aarch64 ABI used on
> linux systems. My understanding after reading that ABI and the prologue
> code for aarch64 is there's nothing that can currently be relied u
On 06/20/2017 04:20 PM, Eric Botcazou wrote:
>> But what you end up depending on is undocumented behavior of a
>> particular kernel implementation. That seems rather unwise.
>
> And it's the single example of such a thing in the entire codebase?
> I don't know the code of the sanitizer much, but
On 06/21/2017 02:41 AM, Richard Earnshaw (lists) wrote:
>> But the stack pointer might have already been advanced into the guard
>> page by the caller. For the sake of argument assume the guard page is
>> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
>> the caller hasn't
On 06/20/2017 05:22 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> But the stack pointer might have already been advanced into the guard
>> page by the caller. For the sake of argument assume the guard page is
>> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
>> the caller
Richard Earnshaw wrote:
> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
> stack which, with at least 8 parameters passed in registers, would allow
> for calls with 40 parameters. There can't be many in that space. Any
> function making calls with more than that might ne
On 21/06/17 09:46, Richard Earnshaw (lists) wrote:
> On 21/06/17 09:44, Andreas Schwab wrote:
>> On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
>>
>>> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
>>> stack which, with at least 8 parameters passed in registers, would
On 21/06/17 09:44, Andreas Schwab wrote:
> On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
>
>> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
>> stack which, with at least 8 parameters passed in registers, would allow
>> for calls with 40 parameters. There can't be m
On Jun 21 2017, "Richard Earnshaw (lists)" wrote:
> A mere 256 bytes for the caller would permit 32 x 8byte arguments on the
> stack which, with at least 8 parameters passed in registers, would allow
> for calls with 40 parameters. There can't be many in that space. Any
> function making calls
On 20/06/17 22:39, Jeff Law wrote:
> On 06/20/2017 03:27 AM, Richard Earnshaw (lists) wrote:
>> On 19/06/17 18:07, Jeff Law wrote:
>>> As some of you are likely aware, Qualys has just published fairly
>>> detailed information on using stack/heap clashes as an attack vector.
>>> Eric B, Michael M --
On 21/06/17 00:22, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> But the stack pointer might have already been advanced into the guard
>> page by the caller. For the sake of argument assume the guard page is
>> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
>> the caller hasn
On Jun 20 2017, Eric Botcazou wrote:
> Right, because the Linux kernel for x86/x86-64 is the only OS flavor that
> doesn't let you probe the stack ahead of the stack pointer. All other
> combinations of OS and architecture we tried (and it's quite a lot) do.
Take a look at do_page_fault in ar
Jeff Law wrote:
> But the stack pointer might have already been advanced into the guard
> page by the caller. For the sake of argument assume the guard page is
> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
> the caller hasn't touched the 0xf1000 page.
>
> If FrameSize >
> But what you end up depending on is undocumented behavior of a
> particular kernel implementation. That seems rather unwise.
And it's the single example of such a thing in the entire codebase?
I don't know the code of the sanitizer much, but from the outside it looks
full of similar tricks...
On 06/20/2017 06:27 AM, Richard Biener wrote:
> On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak wrote:
>> On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote:
>>> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
On 06/20/2017 01:10 PM, Uros Bizjak wrote:
> 74,99% a.outa.ou
On 06/20/2017 02:16 AM, Eric Botcazou wrote:
>
> Right, because the Linux kernel for x86/x86-64 is the only OS flavor that
> doesn't let you probe the stack ahead of the stack pointer. All other
> combinations of OS and architecture we tried (and it's quite a lot) do.
But what you end up depend
On 06/20/2017 03:27 AM, Richard Earnshaw (lists) wrote:
> On 19/06/17 18:07, Jeff Law wrote:
>> As some of you are likely aware, Qualys has just published fairly
>> detailed information on using stack/heap clashes as an attack vector.
>> Eric B, Michael M -- sorry I couldn't say more when I contact
On 06/20/2017 02:37 PM, Eric Botcazou wrote:
>> But then valgrind won't be able to find bugs in the code (storing and later
>> reading stuff into the volatile parts of the stack that could be overwritten
>> by any asynchronous signal). GCC had various bugs in this area and
>> valgrind has been abl
> But then valgrind won't be able to find bugs in the code (storing and later
> reading stuff into the volatile parts of the stack that could be overwritten
> by any asynchronous signal). GCC had various bugs in this area and
> valgrind has been able to report those. Unless the probe instruction
On Tue, Jun 20, 2017 at 10:21:14AM +0200, Eric Botcazou wrote:
> > Out of curiousity, does the old Alpha/VMS stack-checking API meet the
> > requirements? From what I recall, I think it does.
>
> No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
> because of valgrind.
On 06/20/2017 06:17 AM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>
>>> 74,99% a.outa.out [.] test_or
>>> 12,50% a.outa.out [.] test_movb
>>> 12,50% a.outa.out [.] test_
On 06/20/2017 02:27 AM, Richard Earnshaw (lists) wrote:
> On 19/06/17 20:04, Jeff Law wrote:
>> On 06/19/2017 11:50 AM, Joseph Myers wrote:
>>> On Mon, 19 Jun 2017, Jeff Law wrote:
>>>
A key point to remember is that you can never have an allocation
(potentially using more than one alloca
On 06/20/2017 02:21 AM, Eric Botcazou wrote:
>> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
>> requirements? From what I recall, I think it does.
>
> No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
> because of valgrind. I'd personally rat
On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote:
>> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>>
74,99% a.outa.out [.] test_or
12,50% a.outa.out
On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak wrote:
> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>
>>> 74,99% a.outa.out [.] test_or
>>> 12,50% a.outa.out [.] test_movb
>>> 12,50% a.outa.out
On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer wrote:
> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>
>> 74,99% a.outa.out [.] test_or
>> 12,50% a.outa.out [.] test_movb
>> 12,50% a.outa.out [.] test_movl
>
> Could you try notl/notb/negl/negb as well
On 06/20/2017 01:10 PM, Uros Bizjak wrote:
> 74,99% a.outa.out [.] test_or
> 12,50% a.outa.out [.] test_movb
> 12,50% a.outa.out [.] test_movl
Could you try notl/notb/negl/negb as well, please?
Thanks,
Florian
On Tue, Jun 20, 2017 at 12:18 PM, Richard Biener
wrote:
> On Tue, Jun 20, 2017 at 10:03 AM, Uros Bizjak wrote:
>> On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
>>> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>
> Al
On Tue, Jun 20, 2017 at 10:03 AM, Uros Bizjak wrote:
> On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
>> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>>> >
>>> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe st
On 19/06/17 18:07, Jeff Law wrote:
> As some of you are likely aware, Qualys has just published fairly
> detailed information on using stack/heap clashes as an attack vector.
> Eric B, Michael M -- sorry I couldn't say more when I contact you about
> -fstack-check and some PPC specific stuff. This
On 19/06/17 20:04, Jeff Law wrote:
> On 06/19/2017 11:50 AM, Joseph Myers wrote:
>> On Mon, 19 Jun 2017, Jeff Law wrote:
>>
>>> A key point to remember is that you can never have an allocation
>>> (potentially using more than one allocation site) which is larger than a
>>> page without probing the
> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
> requirements? From what I recall, I think it does.
No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
because of valgrind. I'd personally rather change valgrind but...
--
Eric Botcazou
> As some of you are likely aware, Qualys has just published fairly
> detailed information on using stack/heap clashes as an attack vector.
> Eric B, Michael M -- sorry I couldn't say more when I contact you about
> -fstack-check and some PPC specific stuff. This has been under embargo
> for the l
On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>> >
>> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
>> > while it is shorter, is it actually faster or as s
> In the patches Jeff is going to post, we have (at least for
> -fasynchronous-unwind-tables which is on by default on e.g. x86)
> precise unwind info even with the new stack check mode.
> ira.c currently has:
>/* We need the frame pointer to catch stack overflow exceptions if
> t
On 06/20/2017 12:05 AM, Jeff Law wrote:
> On 06/19/2017 03:56 PM, Joseph Myers wrote:
>> On Mon, 19 Jun 2017, Florian Weimer wrote:
>>
>>> I think architectures such as aarch64 without implied stack probing as
>>> part of the function call sequence would benefit most from an ABI
>>> agreement (spli
On 06/19/2017 12:02 PM, Richard Biener wrote:
> On June 19, 2017 8:00:19 PM GMT+02:00, Richard Biener
> wrote:
>> On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek
>> wrote:
>>> On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
After much poking around I concluded that we really
> > Out of curiousity, does the old Alpha/VMS stack-checking API meet the
> > requirements? From what I recall, I think it does.
> Unsure. Is this documented somewhere?
It seems to be in
http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04621389
starting at page 3-54.
On 06/19/2017 12:12 PM, Richard Kenner wrote:
> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
> requirements? From what I recall, I think it does.
Unsure. Is this documented somewhere?
jeff
On 06/19/2017 03:56 PM, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Florian Weimer wrote:
>
>> I think architectures such as aarch64 without implied stack probing as
>> part of the function call sequence would benefit most from an ABI
>> agreement (splitting the probing responsibility in some way b
On 06/19/2017 12:15 PM, Florian Weimer wrote:
> On 06/19/2017 08:02 PM, Richard Biener wrote:
>> Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095
>> would solve the signal atomicity as well. Might be larger and somewhat
>> interfere with CPUs stack engine. Who knows...
>
On Mon, 19 Jun 2017, Florian Weimer wrote:
> I think architectures such as aarch64 without implied stack probing as
> part of the function call sequence would benefit most from an ABI
> agreement (splitting the probing responsibility in some way between
> caller and callee). For architectures wit
On 06/19/2017 11:51 AM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>>>
>>> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
>>> while it is shorter, is it actually faster or as slow as movq $
On 06/19/2017 01:45 PM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 01:04:57PM -0600, Jeff Law wrote:
>> On 06/19/2017 11:50 AM, Joseph Myers wrote:
>>> On Mon, 19 Jun 2017, Jeff Law wrote:
>>>
A key point to remember is that you can never have an allocation
(potentially using more tha
On Mon, Jun 19, 2017 at 01:04:57PM -0600, Jeff Law wrote:
> On 06/19/2017 11:50 AM, Joseph Myers wrote:
> > On Mon, 19 Jun 2017, Jeff Law wrote:
> >
> >> A key point to remember is that you can never have an allocation
> >> (potentially using more than one allocation site) which is larger than a
>
On 06/19/2017 11:50 AM, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Jeff Law wrote:
>
>> A key point to remember is that you can never have an allocation
>> (potentially using more than one allocation site) which is larger than a
>> page without probing the page.
>
> There's a platform ABI issue h
On 06/19/2017 07:50 PM, Joseph Myers wrote:
> There's a platform ABI issue here. At least some kernel fixes for these
> stack issues, as I understand it, increase the size of the stack guard to
> more than a single page. It would be possible to define the ABI to
> require such a larger guard f
On 06/19/2017 08:02 PM, Richard Biener wrote:
> Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095
> would solve the signal atomicity as well. Might be larger and somewhat
> interfere with CPUs stack engine. Who knows...
On x86-64, PUSH REG is just a single byte, so for s
Out of curiousity, does the old Alpha/VMS stack-checking API meet the
requirements? From what I recall, I think it does.
On June 19, 2017 8:00:19 PM GMT+02:00, Richard Biener
wrote:
>On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek
>wrote:
>>On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
>>> After much poking around I concluded that we really need to
>implement
>>> allocation and probing via a "movi
On June 19, 2017 7:29:32 PM GMT+02:00, Jakub Jelinek wrote:
>On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
>> After much poking around I concluded that we really need to implement
>> allocation and probing via a "moving sp" strategy. Probing into
>> unallocated areas runs afoul of va
On Mon, Jun 19, 2017 at 05:50:56PM +, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Jeff Law wrote:
>
> > A key point to remember is that you can never have an allocation
> > (potentially using more than one allocation site) which is larger than a
> > page without probing the page.
>
> There's a
On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
> >
> > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
> > while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
> > or movl $0, (%esp) ?
> Florian ra
On Mon, 19 Jun 2017, Jeff Law wrote:
> A key point to remember is that you can never have an allocation
> (potentially using more than one allocation site) which is larger than a
> page without probing the page.
There's a platform ABI issue here. At least some kernel fixes for these
stack issue
On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>
> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
> while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
> or movl $0, (%esp) ?
Florian raised this privately to me as well. THere's a couple issues.
1. Is th
On Mon, Jun 19, 2017 at 11:07:06AM -0600, Jeff Law wrote:
> After much poking around I concluded that we really need to implement
> allocation and probing via a "moving sp" strategy. Probing into
> unallocated areas runs afoul of valgrind, so that's a non-starter.
>
> Allocating stack space, the
As some of you are likely aware, Qualys has just published fairly
detailed information on using stack/heap clashes as an attack vector.
Eric B, Michael M -- sorry I couldn't say more when I contact you about
-fstack-check and some PPC specific stuff. This has been under embargo
for the last month.
66 matches
Mail list logo
