From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/2] arm64: signal: Report signal frame size to userspace via auxv
Date: Thu, 31 May 2018 18:20:49 +0100 [thread overview]
Message-ID: <20180531172049.GA28915@arm.com> (raw)
In-Reply-To: <20180530104853.GB22983@e103592.cambridge.arm.com>
On Wed, May 30, 2018 at 11:48:59AM +0100, Dave Martin wrote:
> On Tue, May 29, 2018 at 09:42:31PM +0100, Will Deacon wrote:
> > On Fri, May 25, 2018 at 04:17:08PM +0100, Dave Martin wrote:
> > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > > index fac1c4d..8cf112b 100644
> > > --- a/arch/arm64/include/asm/elf.h
> > > +++ b/arch/arm64/include/asm/elf.h
> > > @@ -121,6 +121,9 @@
> > >
> > > #ifndef __ASSEMBLY__
> > >
> > > +#include <linux/bug.h>
> > > +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> > > +
> > > typedef unsigned long elf_greg_t;
> > >
> > > #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> > > @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> > > do { \
> > > NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> > > (elf_addr_t)current->mm->context.vdso); \
> > > + \
> > > + /* \
> > > + * Should always be nonzero unless there's a kernel bug. \
> > > + * If we haven't determined a sensible value to give to \
> > > + * userspace, omit the entry: \
> > > + */ \
> > > + if (likely(signal_minsigstksz)) \
> > > + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> > > } while (0)
> >
> > I think this is the desired behaviour, but now I'm worried that we're forced
> > to have AT_VECTOR_SIZE_ARCH defined as 2 and, whilst you're correct that the
> > ELF loader deals with this gracefuly, the FDPIC loader looks a lot less
> > robust (in particular, my reading is that it decrements the stack pointer
> > and then pushes these entries in reverse order by overloading NEW_AUX_ENT).
>
> config BINFMT_ELF_FDPIC
> /* ... */
> depends on (ARM || (SUPERH32 & !MMU) || C6X)
Ok, that's a relief. The checkpoint stuff is still a bit worrying though
(prctl_set_mm_map).
> The FDPIC loader seems to assume it's 32-bit only and also looks broken
> with regard to auxv:
>
> /* force 16 byte _final_ alignment here for generality */
> #define DLINFO_ITEMS 15
>
> /* ... */
>
> nr = 0;
> csp -= 2 * sizeof(unsigned long);
> NEW_AUX_ENT(AT_EXECFD, ...);
> }
>
> /* ... */
>
> csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
> NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
> #ifdef ELF_HWCAP2
> NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> #endif
> /* 14 more NEW_AUX_ENT() */
>
>
> Looks like commit 2171364d1a92 ("powerpc: Add HWCAP2 aux entry") added
> HWCAP2 without ensuring that space is reserved.
>
> I can try to draft a patch to handle the auxv in a more sane way for
> FDPIC, but either way I don't see that it should be relevant to arm64.
>
>
> AT_IGNORE feels like a bit of a fig leaf, but it's harmless enough. I'm
> happy to add it if you prefer.
The only userspace code I could find that uses it is something that prints
out auxv, but I'd still better spitting it out so we don't have to worry
about being smaller than AT_VECTOR_SIZE_ARCH.
Thanks,
Will
next prev parent reply other threads:[~2018-05-31 17:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 15:17 [PATCH v5 0/2] arm64: signal: Report signal frame size to userspace via auxv Dave Martin
2018-05-25 15:17 ` [PATCH v5 1/2] arm64/sve: Thin out initialisation sanity-checks for sve_max_vl Dave Martin
2018-05-25 15:17 ` [PATCH v5 2/2] arm64: signal: Report signal frame size to userspace via auxv Dave Martin
2018-05-25 15:20 ` Will Deacon
2018-05-29 20:42 ` Will Deacon
2018-05-30 10:48 ` Dave Martin
2018-05-31 17:20 ` Will Deacon [this message]
2018-06-01 8:44 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180531172049.GA28915@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.