This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]