[PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Andrey Konovalov]

On Mon, Apr 1, 2019 at 6:44 PM Andrey Konovalov <andreyknvl at google.com> wrote:
>
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas <catalin.marinas at arm.com> wrote:
> >
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
> > >       if (opt == PR_SET_MM_AUXV)
> > >               return prctl_set_auxv(mm, addr, arg4);
> > >
> > > -     if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > +     if (untagged_addr(addr) >= TASK_SIZE ||
> > > +                     untagged_addr(addr) < mmap_min_addr)
> > >               return -EINVAL;
> > >
> > >       error = -EINVAL;
> > >
> > >       down_write(&mm->mmap_sem);
> > > -     vma = find_vma(mm, addr);
> > > +     vma = find_vma(mm, untagged_addr(addr));
> > >
> > >       prctl_map.start_code    = mm->start_code;
> > >       prctl_map.end_code      = mm->end_code;
> >
> > Does this mean that we are left with tagged addresses for the
> > mm->start_code etc. values? I really don't think we should allow this,
> > I'm not sure what the implications are in other parts of the kernel.
> >
> > Arguably, these are not even pointer values but some address ranges. I
> > know we decided to relax this notion for mmap/mprotect/madvise() since
> > the user function prototypes take pointer as arguments but it feels like
> > we are overdoing it here (struct prctl_mm_map doesn't even have
> > pointers).
> >
> > What is the use-case for allowing tagged addresses here? Can user space
> > handle untagging?
>
> I don't know any use cases for this. I did it because it seems to be
> covered by the relaxed ABI. I'm not entirely sure what to do here,
> should I just drop this patch?

ping

>
> >
> > --
> > Catalin