[PATCH v4] aarch64: enforce >=64K guard size

[Szabolcs Nagy]

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
>