This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH v3 27/28] arm64: signal: Report signal frame size to userspace via auxv
- From: Dave P Martin <Dave dot Martin at arm dot com>
- To: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Cc: "linux-arm-kernel at lists dot infradead dot org" <linux-arm-kernel at lists dot infradead dot org>, nd <nd at arm dot com>, Catalin Marinas <Catalin dot Marinas at arm dot com>, Will Deacon <Will dot Deacon at arm dot com>, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Alex Bennée <alex dot bennee at linaro dot org>, Richard Sandiford <Richard dot Sandiford at arm dot com>, "tokamoto at jp dot fujitsu dot com" <tokamoto at jp dot fujitsu dot com>, "kvmarm at lists dot cs dot columbia dot edu" <kvmarm at lists dot cs dot columbia dot edu>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>
- Date: Wed, 11 Oct 2017 14:14:13 +0100
- Subject: Re: [RFC PATCH v3 27/28] arm64: signal: Report signal frame size to userspace via auxv
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave dot Martin at arm dot com;
- Nodisclaimer: True
- References: <1507660725-7986-1-git-send-email-Dave.Martin@arm.com> <1507660725-7986-28-git-send-email-Dave.Martin@arm.com> <59DDF017.7090203@arm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Wed, Oct 11, 2017 at 11:19:03AM +0100, Szabolcs Nagy wrote:
> On 10/10/17 19:38, Dave Martin wrote:
> > 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