Thread (109 messages) 109 messages, 6 authors, 2017-10-18
STALE3159d

[RFC PATCH v3 27/28] arm64: signal: Report signal frame size to userspace via auxv

From: Dave.Martin@arm.com (Dave P Martin)
Date: 2017-10-11 13:14:13
Also in: kvmarm, linux-arch

On Wed, Oct 11, 2017 at 11:19:03AM +0100, Szabolcs Nagy wrote:
On 10/10/17 19:38, Dave Martin wrote:
quoted
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.

To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.

If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient.  This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
the posix sigaltstack api shall fail with ENOMEM
if smaller than MINSIGSTKSZ stack size is used.

so it is important to note somewhere if AT_MINSIGSTKSZ
is intended to be always >= MINSIGSTKSZ define (which
is rounded up to 5k) or it may be smaller as it provides
the precise value of the largest signal frame.

(i think it makes sense for it to be a precise value,
but then users should do the >= check before calling
the sigaltstack api, so they should be aware of this
issue)
This is a good point, and one that I don't have an answer for yet.

POSIX[1] says that sigaltstack() _shall_ return EPERM if ss_size
< MINSIGSTKSZ.

I don't know the full rationale behind this.

The ENOMEM return here doesn't guarantee that signal delivery will
definitely fail or compromise safety when ss_size or less of stack is
available.

A 0 return doesn't guarantee that signal delivery on the registered
alternate stack will succeed or be safe.

So while the ENOMEM return has some sanity-check value, it's very
limited in its usefulness.


I currently saw no good reason to misrepresent the true signal frame
size in AT_MINSIGSTKSZ, so it is currently a precise value that can be
< MINSIGSTKSZ (and is, in the default case).

In an ideal world, my preference would be to relax the check in
sigaltstack() to check >= AT_MINSIGSTKSZ, but it is technically an ABI
break...


We _could_ paper over this by rounding up the AT_MINSIGSTKSZ value
reported by the kernel to be always >= MINSIGSTKSZ.  This seems ugly,
but may be the most pragmatic option.


Thoughts?

Cheers
---Dave


[1] SUSv7 / IEEE Std 1003.1-2008 (2016): sigaltstack
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaltstack.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help