[PATCH v1 4/4] arm64/mte: Add userspace interface for enabling asymmetric mode

[Catalin Marinas]

On Mon, Mar 07, 2022 at 12:55:28PM -0800, Peter Collingbourne wrote:
> On Mon, Mar 7, 2022 at 7:36 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
> > Only allowing asymmetric mode if both symmetric and async are supported
> > is not that confusing. The only downside is that one cannot ask for
> > asymmetric mode only but is this such a big problem? For testing one can
> > always set the sysfs preferred mode to asymm. It will be some time
> > before we see asymm in production.
> 
> It could be a problem on Android because one of the modes that we
> intend to expose to application developers is "asymm-only" (as opposed
> to "upgradable asymm"). This would be used by developers who need a
> finer grained control over the MTE mode used in their application.
> Although to be honest I'm not 100% certain that we would need this
> mode so perhaps we could live with just the "upgradable asymm" mode.

With the introduction of the preferred mode, we kind of agreed that an
application doesn't necessarily know what it wants and we should leave
this decision to the kernel (via sysfs) as it knows the performance
aspects better. To avoid confusing applications, we changed the TCF
field in prctl() from an exact mode to a supported mode mask so that an
app is not take by surprise. Now, the asymmetric mode is just a
combination of sync and async, and an app just states that it supports
both. It's not any different from the kernel changing the preferred mode
at run-time.

We can later add a new bit, "force asymm" or something if needed while
still requiring that both async and sync bits are set. So I'm tempted to
go with Mark's latest patch, once I looked at it.

> > Assuming we have a different prctl() for setting TCF, what would we
> > report in the current PR_GET_ for existing apps when only the asymm mode
> > was set? By the same logic as the TCF mask breaking current apps, this
> > doesn't work if somehow an app uses the information and, for example,
> > retry a faulting operation indefinitely.
> 
> One option may be to reject the GET with EINVAL if ASYMM is set. This
> should hopefully result in the application acting as if MTE is not
> enabled/supported.

Well, the app still gets TCF faults while it may have concluded that MTE
is disabled. We can't always guess what the user wants (and the history
around this ABI shows this).

Anyway, I'm open to improving the ABI later but I don't think we should
delay the asym MTE patches, especially if we merge Mark's asym removal
from prctl().

-- 
Catalin