[PATCH v1 4/4] arm64/mte: Add userspace interface for enabling asymmetric mode
Catalin Marinas
catalin.marinas at arm.com
Thu Mar 3 02:34:34 PST 2022
On Wed, Mar 02, 2022 at 12:58:48PM -0800, Evgenii Stepanov wrote:
> On Wed, Mar 2, 2022 at 11:33 AM Mark Brown <broonie at kernel.org> wrote:
> > On Wed, Mar 02, 2022 at 10:44:31AM -0800, Evgenii Stepanov wrote:
> > > On Wed, Mar 2, 2022 at 5:10 AM Mark Brown <broonie at kernel.org> wrote:
> > > > On Wed, Mar 02, 2022 at 11:44:53AM +0000, Catalin Marinas wrote:
> > > > > On Tue, Mar 01, 2022 at 04:52:01PM -0800, Evgenii Stepanov wrote:
> >
> > > > > > Extending PR_MTE_TCF_MASK seems bad for backward compatibility. User
> > > > > > code may do "flags =& ~PR_MTE_TCF_MASK" to disable MTE; when compiled
> > > > > > against an old version of the header this would fail to remove the ASYMM
> > > > > > bit.
> >
> > > > > But if the app is compiled against an old version, it wouldn't set
> > > > > MTE_CTRL_TCF_ASYMM either as it doesn't have the definition.
> >
> > > Libraries within a single process can be built against different
> > > header versions. In our case, this is libc vs the app: we expect to
> > > set all 3 mode bits when an app asks for "async" to enable the
> > > mte_tcf_preferred logic. Even if the app is built against an older NDK
> > > and unaware of the Asymm mode existence!
> >
> > I can't see how we can resolve that case in the kernel except by adding
> > a specific call to disable all MTE modes which would obviously only be
> > useful for future proofing given that no existing applications would
> > support it.
>
> One option would be to introduce a new, future-proofed prctl with a
> wider mask, and throw in a few extra reserved bits just in case. Then
> have the legacy prctl always clear MTE_CTRL_TCF_ASYMM.
If this problem is real, we can easily tweak the current proposal so the
that ASYMM can only be set *if* both ASYNC and SYNC are set. IOW, it's
not a specific mode an app requests on its own but rather something the
kernel may choose via the preferred mode if the app opted in. We still
introduce a new bit for ASYMM but not change the mask.
--
Catalin
More information about the linux-arm-kernel
mailing list