Advanced Protection Mode in Android 16 turns on Memory Tagging Extension?

[John Dallman]

Preface: I am not producing an Android app. I work for a software component business, creating shared libraries, compiled from C and C++ code, for use in third-party customers' apps. I test my libraries in a command-line test harness, which I run in the ADB shell. I don't build any apps at all. 

I only use the NDK and the platform tools; I don't even download Android Studio or the SDK. I thus don't use any of the usual Android build systems. Extending my employer's homebrew build system for Unix-style platforms to cross-compile to Android was vastly easier than trying to teach an alien build system about our domain-specific language. 

I am only producing software for 64-bit ARM, because none of the customers want 32-bit code. 

I've encountered a news report that Android 16's Advanced Protection Mode will likely turn on Memory Tagging Extension. The APM documentation doesn't mention that, but it is a potential feature for an unreleased version, so that's quite reasonable. 

As far as I can see from the app developer page about MTE, I can turn on MTE for an app that doesn't declare an MTE requirement with:

• $ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
• $ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name

However, I'm not producing an app. Can I turn on MTE for an executable, and if so, how?

Thanks very much

John Dallman

[Florian Mayer]

You can build and link using clang with -fsanitize=memtag to use MTE for an executable.

[David Faerman]

The app runs on the virtual machine, the executable no...
I guess this flag will affect the virtual machine and not the console. 
Do you need help to build an app that uses lib?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgmdXdRYfsds7wYEbq3SzMkWN_oC-W0wvFTWY5ZK4E6FAA%40mail.gmail.com.

--

 (\__/)
(='.'=)This is Bunny. Copy and paste bunny into your
(")_(")signature to help him gain world domination.

[John Dallman]

On Tue, Mar 11, 2025 at 6:05 PM 'Florian Mayer' via android-ndk <andro...@googlegroups.com> wrote:

You can build and link using clang with -fsanitize=memtag to use MTE for an executable.

OK, but what is the performance effect of that? 

I test the same shared library as I deliver, as in the same binary, and slowing down the delivered code is not acceptable. I could use -fsanitize=memtag in building my test harness, which is a command-line program for the ADB shell environment, linked against the deliverable shared library. Would that mean that MTE was active for the whole process?

Testing a library that was differently compiled from the deliverable would not be considered meaningful testing. Compilers are not that trustworthy. 

 On Tue, Mar 11, 2025 at 6:48 PM David Faerman <ddf...@gmail.com> wrote:

Do you need help to build an app that uses lib?

I'd prefer not to build an app at all, if I can avoid it. I am partially sighted and IDEs are very difficult for me to use.  

John

 

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/8c669271-be8e-4b85-b478-7553eb1a736fn%40googlegroups.com.

[Florian Mayer]

You do definitely don't want to enable that in the library you ship.

You can learn how to enable MTE for binaries at source.android.com.

I will try to get the NDK doc updated.

[John Dallman]

Ok, the simplest way for me would be to set $MEMTAG_OPTIONS on the command line when I start the test harness, thus:

MEMTAG_OPTIONS=(off|sync|async) executable <parameters> 

Does doing that with an executable that isn't compiled -fsanitize=memtag do anything useful? 

If not, testing with -fsanitize=memtag would have to be an occasional thing, rather than an every-build activity.  

Thanks very much,

John

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/8e7899da-50de-4596-8888-7f52605b1456n%40googlegroups.com.

[enh]

On Wed, Mar 12, 2025 at 10:29 AM 'Florian Mayer' via android-ndk
<andro...@googlegroups.com> wrote:
>
> You do definitely don't want to enable that in the library you ship.
>
> You can learn how to enable MTE for binaries at source.android.com.
>
> I will try to get the NDK doc updated.

i'll happily +2 your changes :-)

one thing i noticed that neither s.a.c nor d.a.c explicitly call out
that mte code _will not run_ on devices without mte. (it's sort-of
implied by the "armv9", but (a) pac/bti set a misleading precedent
there and (b) armv9 is necessary but not sufficient.)

> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/8e7899da-50de-4596-8888-7f52605b1456n%40googlegroups.com.

[Florian Mayer]

Yes, it will do something useful. It will provide MTE for heap memory, but not for stack memory or globals.

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgmHVcOwFM5Zpop%2B4HXwXc7W_nH-%2BF7bkFegQ8Nco-C9Rw%40mail.gmail.com.

[John Dallman]

OK, so my course of action seems to be:

1. Acquire a device where I can turn on MTE. This needs to be ARMv9, but that's not a problem these days.  
2. Test a build that is not compiled for MTE on that, with MTE turned on via the environment variable . That gives me MTE checks for heap. If this is (nearly) as fast as running without MTE, consider running my testing with this as standard. 
3. Do an MTE-compiled build and test that under MTE. This will be significantly slower than the non-MTE build, and will only run on ARMv9, so should not be shipped. 
4. There might be a case for shipping MTE-compiled code for software that is all about security, rather than performance, but I don't produce that. 

Does that make sense?   

Thanks again,

John

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAJAyTCCrz_s8Jx6PW8A92TnxeTqS-PugYWwimTjVj_PY4i2UhQ%40mail.gmail.com.

[enh]

On Thu, Mar 13, 2025 at 6:55 AM John Dallman <jgdats...@gmail.com> wrote:
>
> OK, so my course of action seems to be:
>
> Acquire a device where I can turn on MTE. This needs to be ARMv9, but that's not a problem these days.

it's a bit more tricky than that in practice, because you need
bootloader support to actually enable mte. (similar to how you might
have a 64-bit capable chip running a 32-bit kernel or 32-bit
userspace, you need more than just a _chip_ that supports mte
instructions.)

afaik https://developer.android.com/ndk/guides/arm-mte#hwsupport are
the only devices where you can just buy a stock phone off the shelf
and use mte. (if any oem has additional stock phones that support mte,
let me know and i'll make sure you get added to the list!)

> Test a build that is not compiled for MTE on that, with MTE turned on via the environment variable . That gives me MTE checks for heap. If this is (nearly) as fast as running without MTE, consider running my testing with this as standard.
> Do an MTE-compiled build and test that under MTE. This will be significantly slower than the non-MTE build, and will only run on ARMv9, so should not be shipped.

define "significantly". it's a low single-digit percent cost...

> There might be a case for shipping MTE-compiled code for software that is all about security, rather than performance, but I don't produce that.

...so it really comes down to this "do i care about every last bit of
performance, or every last bit of debuggability/mitigation?" tradeoff.

certainly if you're already doing hwasan debugging/testing, you should
consider using mte instead. (and especially if you're actively chasing
a memory error ... sync mode might be too expensive for normal use --
where you might be using asymm instead -- but having the exact
problematic load/store fault can be invaluable for debugging.)

> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgkG%2BsnXpD%2BBst78nri3exNvgNuChZ2sVg_8Jfo9%2Bucf4Q%40mail.gmail.com.

[John Dallman]

> it's a bit more tricky than that in practice, because you need bootloader support to actually enable mte.

Understood. 

> define "significantly". it's a low single-digit percent cost...

I'll measure and see, The need for ARMv9, thus requiring a separate build to continue supporting ARMv8 devices, would be a significant downside. If our customers were asking for MTE, that would make it more acceptable, but they aren't. 

Incidentally, what does Android do if it has a binary that requires ARM v9, and only some of the cores on the device support that? 

Thanks again, 

John

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAJgzZoptEJM5c09E8ppcrWHpxD1PCz%3D84z05oL2j2%3DRFYBCKWQ%40mail.gmail.com.

[Florian Mayer]

On Thursday, March 13, 2025 at 11:29:59 AM UTC-4 enh wrote:

define "significantly". it's a low single-digit percent cost...

fsanitize=memtag enables stack trace recording for all malloc / free calls, so it is likely more expensive than low single-digit percent.

[enh]

On Fri, Mar 14, 2025 at 2:10 PM John Dallman <jgdats...@gmail.com> wrote:
>
> > it's a bit more tricky than that in practice, because you need bootloader support to actually enable mte.
>
> Understood.
>
> > define "significantly". it's a low single-digit percent cost...
>
> I'll measure and see, The need for ARMv9, thus requiring a separate build to continue supporting ARMv8 devices, would be a significant downside. If our customers were asking for MTE, that would make it more acceptable, but they aren't.
>
> Incidentally, what does Android do if it has a binary that requires ARM v9, and only some of the cores on the device support that?

i don't think _arm_ supports such a configuration even for weird
custom systems, but even if they do, that's not something android
supports more generally --- you can only claim features that all cores
support.

> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgmTix%2BucOGg0qax_eJgkCgmyhu2VU6Ej1J%2BDmGrHmtk0A%40mail.gmail.com.

[yu...@unity3d.com]

Yeah the ABI filtering is not there, but you can write armv9 specific code and do dispatch using function multi-versioning https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning - I hope it already found its way into the NDK.

[John Dallman]

> > Incidentally, what does Android do if it has a binary that requires ARM v9, and only some 

> > of the cores on the device support that?
>

> I don't think _arm_ supports such a configuration even for weird

> custom systems, but even if they do, that's not something android
> supports more generally --- you can only claim features that all cores
> support.

I thought I had a counter-example for that, but forgot that Cortex-X1 isn't ARMv9!

Thanks,

John

To view this discussion visit https://groups.google.com/d/msgid/android-ndk/CAJgzZor_UJ3RRhNyx93z-yT0g6gMSYoCgQLW%3DbL0T63R5Q0zvg%40mail.gmail.com.

[John Dallman]

It might well not be for me: the library I'm testing very rarely calls malloc/free (or new/delete). It requests memory from the C run-time library in big hunks and runs its own memory management inside them. It does this for two reasons:

1. It has a number of characteristic allocation sizes, and maintaining pools of chunks that size reduces fragmentation. 
2. The application it's embedded in needs to be able to control its memory usage. It is required to provide callbacks for memory allocation and freeing, and can use those to monitor memory usage. 

John

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/android-ndk/88821c78-2fb4-43a5-bd6e-72654f89f216n%40googlegroups.com.