arm64 uaccess series

[Catalin Marinas]

On Tue, Jul 09, 2024 at 10:12:34AM -0700, Linus Torvalds wrote:
> On Tue, 9 Jul 2024 at 09:52, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Jul 09, 2024 at 09:01:58AM -0700, Linus Torvalds wrote:
> > > I've been running variations of this on my Altra machine for the last
> > > month or more, but admittedly my loads are trivial and uninteresting (ie
> > > mostly kernel builds).  So my test coevrage is not very wide.
> >
> > I can temporarily pull this branch and 'runtime-constants' into arm64
> > 'for-kernelci'. It's an unstable branch, it doesn't end up in -next.
> > It's just pointed at by various CI systems to get some wider testing. I
> > can even pull all four branches if you think it's useful.
> 
> Pulling all four branches is probably just as well. The only one that
> doesn't have any arm64 changes at all is the link_path_walk one, but
> looking at code generation of link_parh_walk (and strncpy_from_user())
> was why the three other branches exist, so they are related in that
> way ;)

Done, pushed the branch. It's usually picked up by CI systems in a day
or two.

> > We are still debating this. I don't think the ABI change is that bad
> > but, OTOH, user programs with MTE enabled (which would relax the
> > access_ok()) haven't been tested much. As a kind of precaution, we could
> > enforce the current behaviour via the sysctl abi.tagged_addr_disabled
> > and wire it up via a static key. Currently this sysctl only prevents
> > setting of the TIF_TAGGED_ADDR flag (and implicitly enforces stricter
> > checks in access_ok()).
> 
> I'd actually be interested to hear if anybody really notices. If the
> plan is to make a future sane ABI wrt this, wouldn't it be nice if it
> turns out nobody even cares about the odd legacy behavior and we can
> just leave it behind?
> 
> IOW, why go to extra pain if it turns out that there really are no
> reasons to do that?

It depends on how late we find out some weird application relying on the
current behaviour. The sysctl would have been a quick hack for a distro
to restore the old behaviour without patching the kernel. But I agree
that most likely it's just an unnecessary extra pain. We can try our
luck.

-- 
Catalin