[PATCH v19 00/15] arm64: untag user pointers passed to the kernel
Dave Martin
Dave.Martin at arm.com
Fri Aug 9 09:28:00 UTC 2019
On Fri, Aug 09, 2019 at 10:00:17AM +0100, Catalin Marinas wrote:
> On Thu, Aug 08, 2019 at 04:09:04PM -0700, Kees Cook wrote:
> > On Thu, Aug 08, 2019 at 03:33:00PM -0700, Andrew Morton wrote:
> > > On Thu, 8 Aug 2019 14:12:19 -0700 Kees Cook <keescook at chromium.org> wrote:
> > >
> > > > > The ones that are left are the mm ones: 4, 5, 6, 7 and 8.
> > > > >
> > > > > Andrew, could you take a look and give your Acked-by or pick them up directly?
> > > >
> > > > Given the subsystem Acks, it seems like 3-10 and 12 could all just go
> > > > via Andrew? I hope he agrees. :)
> > >
> > > I'll grab everything that has not yet appeared in linux-next. If more
> > > of these patches appear in linux-next I'll drop those as well.
> > >
> > > The review discussion against " [PATCH v19 02/15] arm64: Introduce
> > > prctl() options to control the tagged user addresses ABI" has petered
> > > out inconclusively. prctl() vs arch_prctl().
> >
> > I've always disliked arch_prctl() existing at all. Given that tagging is
> > likely to be a multi-architectural feature, it seems like the controls
> > should live in prctl() to me.
>
> It took a bit of grep'ing to figure out what Dave H meant by
> arch_prctl(). It's an x86-specific syscall which we do not have on arm64
> (and possibly any other architecture). Actually, we don't have any arm64
> specific syscalls, only the generic unistd.h, hence the confusion. For
> other arm64-specific prctls like SVE we used the generic sys_prctl() and
> I can see x86 not being consistent either (PR_MPX_ENABLE_MANAGEMENT).
>
> In general I disagree with adding any arm64-specific syscalls but in
> this instance it can't even be justified. I'd rather see some clean-up
> similar to arch_ptrace/ptrace_request than introducing new syscall
> numbers (but as I suggested in my reply to Dave, that's for another
> patch series).
I had a go at refactoring this a while ago, but it fell by the wayside.
I can try to resurrect it if it's still considered worthwhile.
Cheers
---Dave
More information about the amd-gfx
mailing list