arm64 uaccess series

Linus Torvalds torvalds at linux-foundation.org
Tue Jul 9 10:12:34 PDT 2024


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 ;)

> 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?

                 Linus



More information about the linux-arm-kernel mailing list