This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] aarch64: enforce >=64K guard size
On 16/07/18 13:59, Alexander Monakov wrote:
On Mon, 16 Jul 2018, Szabolcs Nagy wrote:
on aarch64 safe behaviour is only guaranteed if the
guard is >=64k, a smaller guard does not guard against
stack overflow, so what's the point of a smaller guard?
user code cannot reason about stack usage in any sensible
way so it cannot be smart about the guard size, yet there
is lot of existing code setting the guard size explicitly
to a single page. the only effect of granting those
settings is to make code unsafe on systems with smaller
than 64k page size.
I think a better explanation is required here, because user code
can, at least in principle, ensure the following guarantees:
- no signals will be delivered to that thread
- no recursive call chains are possible
- no variable-size on-stack allocations exist
in which case it is possible to compute an upper bound on worst-case
stack consumption by dumping per-function stack usage and the call graph.
(recursion is actually not an issue for the guard as it does not
affect the maximum stack increment.)
such bound can only be computed for a particular code generation,
(so relying on it is very fragile: same target abi, same compiler,
different cflags and the user computed guard size is no longer
valid) and it requires complete control of the code running on
the thread, including the c runtime, which an application cannot
do (unless the c runtime gives guarantees about worst-case stack
increment for its entry points, which glibc does not do)
I understand the "no signals" clause is not so simple, as setXid calls
implicitly deliver a signal to each thread, and it's easy to miss that.
I think there's no readily available tool to perform the above
computation, which suggests that people rarely do that in practice.
implementation internal things can always consume stack in
undefined ways (be it signals or whatever) because the stack
is not part of the language standard and stack usage is not
observable in any portable way.
of course in practice it would be bad if the implementation
randomly allocated large chunks of stack space, but users
should not make assumptions about stack usage.
but the real reason why it's ok to round up the user setting
is that there is no practical difference between a 4k and 64k
address space hole on aarch64: it won't cause resource
exhaustion issues, so i see no drawback, it only makes things
safer.
Alexander