<div dir="ltr">On Sun, Nov 10, 2013 at 1:46 PM, PaX Team <span dir="ltr"><<a href="mailto:pageexec@freemail.hu" target="_blank">pageexec@freemail.hu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8 Nov 2013 at 17:37, Richard Smith wrote:<br>
<br>
> I don't think you've answered my main question: what semantics do you want<br>
> the returned pointer to have (and how can any correct code ever do anything<br>
> with the pointer)? If you just want some approximation of the stack pointer<br>
> to use as a key, __builtin_frame_address seems like it would work.<br>
<br>
</div>linux can process IRQs on a separate kernel stack (instead of the normal<br>
per-process kernel stacks) in order the reduce the chances of kernel stack<br>
overflows (they're very limited in size). now linux also wants to be able<br>
to walk across these stacks when producing a diagnostic backtrace (that may<br>
very well happen while processing an IRQ on its own stack). different archs<br>
solve this problem of finding one stack from another in different ways.<br>
<br>
specifically the i386 kernel (arch/x86/kernel/irq_32.c) saves the 'current<br>
stack pointer' value somewhere on the IRQ stack (before switching the esp<br>
register, which is done in asm) and the backtrace code (that loop in dump_trace<br>
in arch/x86/kernel/dumpstack_32.c) 'knows' where to find it and continues<br>
the trace from this saved stack pointer value. all this logic probably breaks<br>
the standard in a dozen ways so strictly speaking it's nowhere near compliant<br>
but 'it works' (with gcc anyway ;). (as a sidenote, there's more stack walking<br>
code in linux that assumes certain compiler behaviour but let's fix one problem<br>
at a time)<br>
<br>
now with that background let me try to answer your questions:<br>
<br>
- __builtin_frame_address is indeed good enough for this purpose (and i can't<br>
  find more use of the stack register in C, but maybe Behan knows of more where<br>
  an exact value is important)<br></blockquote><div><br></div><div>That seems like a good answer, if it works. It seems like we could choose to copy everything on the current stack frame into some global storage and back around any call to __builtin_stack_address, and thus one possible correct implementation would be to always return the frame pointer.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- the resulting value is expected to be a valid address (at the time it's taken)<br>
  as the kernel *will* dereference it later but there're no other requirements.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Do you *also* need a guarantee that the stack pointer will not change<br>

> between the call to __builtin_stack_address and the end of the function<br>
> (except in callees)?<br>
<br>
</div>no, it just has to be an address that belongs to the current stack frame at the<br>
time. basically it'll define the start address from which the kernel will look<br>
for certain things (such as code addresses in the hope that saved return addresses<br>
will be found this way) on the stack.<br>
<div class="im"><br>
> Can we reorder a call to alloca() past __builtin_stack_address?<br>
> Can we reorder the initialization of a VLA past a call to<br>
> __builtin_stack_address? Can the backend choose to perform a stack<br>
> adjustment afterwards?<br>
<br>
</div>yes for all.</blockquote><div><br></div><div>Thanks. Seems like the kernel can rely on being able to read through pointers that used to point to the stack because it knows that the readable portion of the stack never shrinks, right? (This could go wrong for programs using segmented stacks.) </div>
</div></div></div>