From: Dave Martin <Dave.Martin@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arch@vger.kernel.org, linux-man@vger.kernel.org,
Michael Kerrisk <mtk.manpages@gmail.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 6/6] prctl.2: Add tagged address ABI control prctls (arm64)
Date: Mon, 15 Jun 2020 15:51:16 +0100 [thread overview]
Message-ID: <20200615145115.GL25945@arm.com> (raw)
In-Reply-To: <20200610174205.GL26099@gaia>
On Wed, Jun 10, 2020 at 06:42:05PM +0100, Catalin Marinas wrote:
> On Wed, Jun 10, 2020 at 05:42:09PM +0100, Dave P Martin wrote:
> > On Wed, Jun 10, 2020 at 04:26:34PM +0100, Catalin Marinas wrote:
> > > On Wed, Jun 10, 2020 at 11:06:42AM +0100, Dave P Martin wrote:
> > > > On Tue, Jun 09, 2020 at 06:22:32PM +0100, Catalin Marinas wrote:
> > > > > On Wed, May 27, 2020 at 10:17:38PM +0100, Dave P Martin wrote:
> > > > > > +.IP
> > > > > > +The level of support is selected by
> > > > > > +.IR "(unsigned int) arg2" ,
> > > > >
> > > > > We use (unsigned long) for arg2.
> > > >
> > > > Hmmm, not quite sure how I came up with unsigned int here. I'll just
> > > > drop this: the type in the prctl() prototype is unsigned long anyway.
> > > >
> > > > The type is actually moot in this case, since the valid values all fit
> > > > in an unsigned int.
> > >
> > > Passing an int doesn't require that the top 32-bit of the long are
> > > zeroed (in case anyone writes the low-level SVC by hand).
> >
> > Fair point, I was forgetting that wrinkle. Anyway, the convention in
> > this page seems to be that if the type is unsigned long, we don't
> > mention it, because the prctl() prototype says that already.
> >
> > Question: the glibc prototype for prctl is variadic, so surely any
> > calls that don't explicitly cast the args to unsigned long are already
> > theoretically broken? The #defines (and 0) are all implicitly int.
> > This probably affects lots of prctls.
> >
> > We may get away with it because the compiler is almost certainly going
> > to favour a mov over a ldr for getting small integers into regs, and mov
> > <Wd> fortunately zeroes the top bits for us anyway.
>
> So does LDR Wd.
>
> Anyway, I think glibc (or my reading of it) has something like like:
>
> register long _x1 asm ("x1") = _x1tmp;
>
> before invoking the SVC. I assume this would do the right conversion to
> long. I can't tell about other libraries but I'd say it's their
> responsibility to convert the args to long before calling the kernel's
> prctl().
Ignore me. I was worrying that glibc would propagate junk in the high
bits of int arguments, due to treating them as longs. Actually, it
will, but it doesn't matter where we explicitly cast the argument to int
inside the kernel (thanks as usual to -fno-strict-overflow).
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-15 14:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 21:17 [PATCH v2 0/6] prctl.2 man page updates for Linux 5.6 Dave Martin
2020-05-27 21:17 ` [PATCH v2 1/6] prctl.2: ffix use literal hyphens when referencing kernel docs Dave Martin
2020-05-28 6:05 ` Michael Kerrisk (man-pages)
2020-05-27 21:17 ` [PATCH v2 2/6] prctl.2: Add PR_SPEC_INDIRECT_BRANCH for SPECULATION_CTRL prctls Dave Martin
2020-05-28 7:01 ` Michael Kerrisk (man-pages)
2020-06-01 13:51 ` Dave Martin
2020-06-09 11:00 ` Michael Kerrisk (man-pages)
2020-05-27 21:17 ` [PATCH v2 3/6] prctl.2: Add PR_SPEC_DISABLE_NOEXEC " Dave Martin
2020-05-28 6:57 ` Michael Kerrisk (man-pages)
2020-05-28 13:45 ` Waiman Long
2020-05-27 21:17 ` [PATCH v2 4/6] prctl.2: Add SVE prctls (arm64) Dave Martin
2020-06-09 9:57 ` Will Deacon
2020-06-09 14:11 ` Dave Martin
2020-06-09 14:49 ` Will Deacon
2020-06-10 9:44 ` Dave Martin
2020-06-10 10:16 ` Will Deacon
2020-06-10 12:48 ` Dave Martin
2020-06-09 11:39 ` Michael Kerrisk (man-pages)
2020-06-10 9:45 ` Dave Martin
2020-05-27 21:17 ` [PATCH v2 5/6] prctl.2: Add PR_PAC_RESET_KEYS (arm64) Dave Martin
2020-06-09 10:02 ` Will Deacon
2020-06-09 11:03 ` Michael Kerrisk (man-pages)
2020-06-09 11:36 ` Michael Kerrisk (man-pages)
2020-06-09 14:16 ` Dave Martin
2020-06-09 18:11 ` Michael Kerrisk (man-pages)
2020-05-27 21:17 ` [RFC PATCH v2 6/6] prctl.2: Add tagged address ABI control prctls (arm64) Dave Martin
2020-06-09 11:04 ` Michael Kerrisk (man-pages)
2020-06-09 13:38 ` Will Deacon
2020-06-09 17:22 ` Catalin Marinas
2020-06-10 10:06 ` Dave Martin
2020-06-10 15:26 ` Catalin Marinas
2020-06-10 16:42 ` Dave Martin
2020-06-10 17:42 ` Catalin Marinas
2020-06-15 14:51 ` Dave Martin [this message]
2020-06-24 9:54 ` Michael Kerrisk (man-pages)
2020-06-24 10:29 ` Dave Martin
2020-05-28 7:11 ` [PATCH v2 0/6] prctl.2 man page updates for Linux 5.6 Michael Kerrisk (man-pages)
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=20200615145115.GL25945@arm.com \
--to=dave.martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).