Happy to share that our work analyzing the performance of ARM Memory tagging extensions on real hardware has been accepted at USENIX Security 2026. We look at the performance of MTE on Pixel 8, Pixel 9, AmpereOne CPUs, and even have some preliminary analysis of MTE performance on the Mac M5. This covers MTE on phones, laptops, and server chips.

Context: Memory safety bugs represent the majority (50% to 70%) of bugs in systems like Chrome, Windows etc. ARM's memory tagging is a hardware feature that can be used to probabilistically detect memory safety bugs. Unfortunately, most discussions of MTE's performance overhead so far have been vague. Since MTE is now available in a handful of devices we decided to take a look!

Highlights
----------------
- Performance overheads of MTE can vary widely according to micro-architecture and benchmark.
- SYNC MTE can indeed be implemented efficiently as shown by the implementation on the AmpereOne, Mac M5, and Pixel's Little core. But micro-architectural details can lead to large overheads on specific benchmarks. E.g.: Causes a factor of 2x to 6x on Pixel's performance core, 1.8x on Pixel's big core, 1.43x on AmpereOne cores, and 1.29x on Mac M5 cores. Interestingly, on receiving our report, Ampere noted they had also discovered this internally and have fixed this in future chips.
- ASYNC MTE is faster than SYNC MTE and imposes very low overheads on Pixel's Performance and Little core. However, counter to conventional wisdom, subtle micro-architectural issues can compromise in ASYNC MTE's performance on specific workloads and micro-architectures - E.g., 1.8x on Pixel's big core.
- MTE's runtime support matters! The Linux kernel's support for MTE sometimes resulted in 25% throughput drop on Memcached on AmpereOne chips due to an assumption made based on an ambiguous part of the ARM MTE specification. We submitted a patch for this to the Linux kernel mailing list which eliminates almost all of the overhead on this benchmark.
- Prior academic work tested MTE using performance analogs. This was reasonable since MTE hardware has only been available recently. Unfortunately, we see that the analogs don't reflect real world performance. Further, assumptions of MTE performance from prior work on real devices are at best, incomplete (and at worst: wrong) due to testing on a single MTE micro-architecture or in some cases: benchmarking bugs.
- Finally, for use cases beyond enforcing memory safety, the first generation of MTE implementations has mixed results. Data tracing and copy elision can use MTE for speedups today, while CFI and SFI (in-process sandboxing) don't yet show clear performance with today's MTE implementations.

I suspect USENIX will have the papers up soon, but in case you want to look through the specific details, a copy of the paper is available here.
https://shravanrn.com/pubs/mte-extended

Kudos to the whole team and especially to Taehyun for driving this work!

Team: Taehyun Noh (@taehyun), Yingchen Wang, Tal Garfinkel (https://www.linkedin.com/in/tal-garfinkel-937528/), Mahesh Madhav(https://www.linkedin.com/in/mahesh-madhav/), Daniel Moghimi (@flowyroll), Mattan Erez(https://lph.ece.utexas.edu/merez/), Shravan Narayan (@shravanrn)

Also shout out to Mahesh Madhav and Carl Worth from Ampere for their help with Ampere infrastructure and identifying/testing kernel patches for MTE performance.

OpenSSH runs a large number of tests via Github Runners, both Github supplied ones on a public repo, and on selfhosted runners on a private repo. The latter covers a bunch of platforms Github doesn't support, and is private not because we don't want it accessible (in fact we would prefer it be public) but because as far as we can tell, making it public would represent a significant security risk.

Github have announced that they will begin charging per-minute fees for Github Actions self-hosted runners starting next year. These fees apply only to runners on private repos, but "actions will remain free in public repositories."[0] This is going to be a significant problem for us.

Github's own documentation points out allowing selfhosted runners on public repositories is unsafe, because it's a potential remote code execution vector via running arbitrary workflows in modified pull requests:

"As a result, self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment."[2]

There are some controls[1], but the documentation on them doesn't exactly instill confidence (emphasis on the weasel words added):

"Anyone can fork a public repository, and then submit a pull request that proposes changes to the repository's GitHub Actions workflows. [...] To *help* prevent this, workflows on pull requests to public repositories from *some* outside contributors will not run automatically, and *might* need to be approved first. Depending on the "Approval for running fork pull request workflows from contributors" setting, workflows on pull requests to public repositories will not run automatically and *may* need approval if: The pull request is created by a user that requires approvals based on the selected policy.[or] The pull request event is triggered by a user that requires approvals based on the selected policy."

All of this uncertainty could be addressed by completely disabling pull requests on a repo, but while that has been requested many many times over the course of a decade([3] [4]), this is still not possible.

It *is* possble to *temporarily* disable pull requests on a repository via Interaction Limits[5], but using this as a security control that (silently?) fails open after some amount of time is problematic to say the least. The required functionality is almost there, it just needs a "forever" option.

So, in summary: self-hosted runners remain free as long as you run them on public repos, which you shouldn't because it's unsafe, unless you also disable pull requests, which you probably can't.

[0] https://resources.github.com/actions/2026-pricing-changes-for-github-actions/
[1] https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories
[2] https://docs.github.com/en/actions/reference/security/secure-use
[3] https://github.com/orgs/community/discussions/8907
[4] https://github.com/dear-github/dear-github/issues/84
[5] https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository