On 01/05/2018 06:36 AM, John Reiser wrote:
1) Each on-stack allocation (both fixed- and variable-sized [alloca()])
always is present and "dirty". The stack probe (or the incremental growth
of <= PAGE_SIZE bytes at a time) forces it to consume separate, real RAM.
In a local declaration such as this, the comment is not valid:
char temp[1000000]; /* only a prefix matters for resource
consumption */
Doesn't the kernel preemptively map in stack mappings anyway, to avoid
page faults?
On the plus side, the probing makes valgrind happy and it won't warn
about stack switches in these cases.
2) The explicit write by the stack probe can mask a memcheck(valgrind)
violation, at least until memcheck groks the probe.
No, this is not a problem with -fstack-clash-protection. A lot of work
went into making the probes completely invisible on the primary
architectures. This is *not* -fstack-check, and the countless bugs
people have run into with that are not applicable to it.
(There have been some bugs, of course, but such is life with new
features. But the design is sound and specifically tied to what we need
for stack overflow detection.)
3) The stack must be at least one page of real RAM, with at least
one terminating guard page that has PROT_NONE. No more threads
with small stacks packed sequentially adjacent.
The guard page is only needed if stack overflows are to be detected (and
the ABI required the guard page since the initial round of stack clash
fixes many years ago). With -fstack-clash-protection, if a probe
happens outside the allocated stack, the code would have placed a data
object or return address at this place there as well even if it had been
compiled without -fstack-clash-protection. The probes are never out of
range. The guard page is only needed so that there is something to
cause a fault, but they are not needed for correct operation.
4) All code must be generated by a compiler that enforces the probing
policy,
and all language support run-time routines also must enforce the policy.
No mixing of old or foreign compilers with the new gcc.
No mixing of old or foreign C libraries with the new glibc.
The code is fully interoperable, and there is no immediate ABI impact.
On x86, POWER, Z, non-noreturn functions compiled with
-fstack-clash-protection fully protect themselves, no matter how the
caller has been compiled. But of course, if the caller has crossed the
guard region, then nothing can be done about that.
Most other language run-times already have stack overflow detection
(OpenJDK, Python, Lua, MLton, Go come to my mind). Of course, if you do
not use GCC, a GCC feature does not help you, but then, GCC is the
official Fedora compiler.
Direct use by an app developer of the 'clone' system call is forbidden.
The raw system call does not care about stacks at all. It shares or
duplicates the caller's stack. The explicit stack argument is a glibc
thing and in general fairly useless to those who need the clone system call.
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
