[PATCH] arm64/mte: Remove asymmetric mode from the prctl() interface

Will Deacon will at kernel.org
Wed Mar 9 04:35:51 PST 2022


On Tue, Mar 08, 2022 at 02:22:30PM +0000, Mark Brown wrote:
> As pointed out by Evgenii Stepanov one potential issue with the new ABI for
> enabling asymmetric is that if there are multiple places where MTE is
> configured in a process, some of which were compiled with the old prctl.h
> and some of which were compiled with the new prctl.h, there may be problems
> keeping track of which MTE modes are requested. For example some code may
> disable only sync and async modes leaving asymmetric mode enabled when it
> intended to fully disable MTE.
> 
> In order to avoid such mishaps remove asymmetric mode from the prctl(),
> instead implicitly allowing it if both sync and async modes are requested.
> This should not disrupt userspace since a process requesting both may
> already see a mix of sync and async modes due to differing defaults between
> CPUs or changes in default while the process is running but it does mean
> that userspace is unable to explicitly request asymmetric mode without
> changing the system default for CPUs.
> 
> Reported-by: Evgenii Stepanov <eugenis at google.com>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> Cc: Peter Collingbourne <pcc at google.com>
> Cc: Joey Gouly <joey.gouly at arm.com>
> Cc: Branislav Rankov <branislav.rankov at arm.com>
> ---
> 
> Just putting this proposal out there as a concrete patch, I'm not sure
> that it's actually the best option however even if it's not what we end
> up going for longer term we may wish to apply it just now since we're
> getting near to the merge window and it means we don't add anything to
> the prctl() ABI this release.  It'd mean we could still get some support
> for asymmetric mode in userspace processes while giving us a cleaner
> slate to figure out what we want to do with the ABI.
> 
>  Documentation/arm64/memory-tagging-extension.rst | 16 ++++++++--------

This doesn't apply on for-next/mte due to conflicts here ^^

Will



More information about the linux-arm-kernel mailing list