arch/arm64: Armv8 MTE - Memory Tagging Extensions

[michpappas]

Prerequisite checklist

• Read the contribution guidelines regarding submitting new changes to the project;
• Tested your changes against relevant architectures and platforms;
• Ran the checkpatch.pl on your commit series before opening this PR;
• Updated relevant documentation.

Base target

• Architecture(s): [arm-64]
• Platform(s): [N/A]
• Application(s): [N/A]

Additional configuration

Description of changes

Memory tagging is a hardware protection against memory safety violations in the scope of both spatial (eg buffer overflows) and temporal (eg use-after-free) safety.

The idea behind MTE is to restrict pointer access to predefined blocks of memory. This is done by tagging memory regions and pointers, and check for match upon access. A mismatch generates a Tag Check Fault (TCF). Specifically, the architecture introduces the concepts of:

• Physical Address Tags, which are and are stored into the upper bits of pointers.
• Allocation Tags, which tag blocks of memory. These are stored into the Tag PA Space, an IMPLEMENTATION
  DEFINED memory space that is logically different from the Data PA Space.

Combined together, these ensure that only memory within a given block is accessed. For instance, in the case of a buffer overflow, memory access outside the allocated bufer will cause a tag mismatch. Similarly, assuming that freeing memory re-tags the freed region, a use-after-free attempt will also cause a tag mismatch. Other accesses like prefetches, cache maintenance, translation table walks, accesses to the tag PA space, etc are always tag unchecked.

MTE requires support from the operating system. For example, addresses returned by malloc() must be tagged. Notice that the tags are only 4-bits wide, ie tags can have 16 possible values. Consequently, the same tag may be used on different regions on a given time, or that a region may have different tag values during time.

Architecture support

Armv8.5 introduces Memory Tagging as an OPTIONAL feature, through:

• FEAT_MTE: Basic tag management instructions, system instructions. Without MTE2 some of these are not usable (UNDEFINED, UNPREDICATBLE).
• FEAT_MTE2: Full MTE support.
• FEAT_MTE3: Support for asymmetric TCF reporting.

Armv8.7 makes FEAT_MTE3 a mandatory when FEAT_MTE2 is implemented.

Compiler support

GCC-9

Introduces initial MTE support with march=armv8.5-a+memtag. According to the GCC docs,
"This option is only to enable the extension at the assembler level and does not affect code generation".

GCC-10

Introduces MTE heap tagging support. The 'memtag' option enables memory tagging intrinsics.

At the time of writing, MTE stack tagging is not yet supported.

Hardware Support

None. At the time of writing MTE is only known to be implemented in QEMU, and in Arm FVP.

Lately vendor support for MTE has started to appear on the news. Notable examples include the DSU-110 DynamIQ cluster from Arm for Armv9, and Samsung's Exynos 2200.

Changes introduced in this series

This PR implements basic MTE support for arm64-based platforms, with the following changes:

• A new configuration option to enable MTE (CONFIG_ARM64_FEAT_MTE).
• A new memory type for tagged memory. This is set as the default type of Normal Memory when MTE is enabled.
• A new header under arch/arm/arm64/ with macros for generating, storing and loading tags. Currently only loads / stores of allocations to granule is suppported (ldg / sdg). Additional functionality such as store allocation tag with zeroing (sdgz), store allocation tag for blocks (sdgm), etc is not implemented.
• Platform helpers for MTE initialization, and tagging of contiguous regions.
• A new configuration option to enable memory tagging, and additional options to control tag check fault reporting (CONFIG_ARM64_FEAT_MTE_TCF_[SYNC,ASYNC,ASYMMETRIC]).
• A check in the IRQ vector to check for accumulated errors when tag check fault reporting is set to Async or Asymmetric.

An additional commit demonstrates how an allocator can be modified to support MTE, by introducing instrumentation to ukalloc. This is a fairly simple implementation that tags memory on uk_malloc_ifpages(), uk_free_ifpages(), and uk_posix_memalign_ifpages(). The region tagged is equal to the size requested by the user aligned to the MTE granule, ie 16 bytes. Any attempt to access memory outside that region, including allocation metadata, will cause a fault.

Resources

1. Memory Tagging Extension Whitepaper
2. Learn the architecture: Providing protection for complex software
3. The Arm Architecture Reference Manual Armv8, for Armv8-A architecture profile

[michpappas]

@marcrittinghaus, @skuenzer I would like your comments on this one, especially in the topics below.

The changes in the allocator: These somewhat relate to the discussion in #191 on whether we should add a wrapper around alloc for these things. My understanding is that this would help with any allocators provided by Unikraft, but not with allocators in external implementations of libc (newlib / musl). The other option is to instrument the allocator's implementation. This has the drawback that some work needs to be duplicated for every allocator, but also benefits in performance, as you can optimize calloc(), malloc() for large blocks etc using instructions like "store allocation tag with zeroing" (sdgz), "store allocation tag for blocks" (sdgm), etc. CC: @vladandrew

The implementation of asynchronous TCF reporting: My implementation comes with a penalty of one register check per IRQ. IIRC linux checks the TFSR on task switch, thread switch, and when swicthing between EL0 and EL1. We don't have most of these choices on Unikraft, so IRQ is one of our few choices. If people find this an issue, and would rather check in other places (say in the scheduler), we can make checks in IRQ optional and provide alternatives via KConfig.

[michpappas]

This PR depends on #434. As RNG support is a dependency for MTE, I am adding the relevant commits here too. Once #434 is merged I will rebase this PR to staging.

[craciunoiuc]

Hey @michpappas,

I did an initial pass over this PR and it looks pretty ok, I left some comments.

One thing that bothers me a bit is the the overall spam of ifdef/endif guards.
Unfortunately I'm not sure if there is a better way to this, as the protected code is pretty small and non-repetitive so I'm not sure if it can be abstracted.

Other than this, the PR looks okay! I'll try it out after the RNG PR is in.

I'll let @skuenzer now give his input on this.

Cezar

[craciunoiuc]

I'll go ahead and test it again, just to make sure

Edit: Still works like a charm 🥇

[marcrittinghaus]

@michpappas Thanks for putting the extra effort into this!

1. Now we arch/arm64/include/uk/asm/memtag.h includes errno.h for ukarch_memtag_ini() to return -ENOTSUP as you requested on your previous comment.

Ok, no problem. We discuss the introduction of an uk/errno.h also for the code conventions and can adapt later if needed.

2. I left handling of asynchronous reporting out of ukarch_memtag, and only conditional to MTE.

Yes, makes sense 👍🏻

3. In theory ukalloc could be changed to have all memory tagging operations unconditional, and have ukarch_memtag stub them out if memory tagging is not supported, or not enabled. Not sure if that's what you had in mind. Saying that, all this is subject to change anyway, as we need a common memory tagging library that will use KASAN if a hardware implementation is not available (in linux MTE is also part of the KASAN subsystem as "hardware KASAN"). Also see that the changes in alloc.c for KASAN are very close to MTE. All this was dicussed during the security workshop in Sinaia, yet I would rather get this PR merged first and work with @vladandrew towards the libmemtag as KASAN gets on the way to be merged on 0.12, rather going over endless iterations of reworks here. CC: @hlef

Yes, when I wrote the comment, I had in mind to avoid #ifdefs where possible to reduce code clutter. I wasn't aware of the planned integration with KASAN to be honest as I am not reviewing that PR and not really wrapped my head around it that much 🙈, but it totally makes sense 👍🏻 Nevertheless, I think it is cleaner now. Just like with the random API you can now use a common ukarch API in KASAN to use HW features if available. So at least it will make KASAN cleaner in the end 😃 Thanks for making the changes 🙏🏻

@craciunoiuc Thanks for checking it out!

[michpappas]

Yes, when I wrote the comment, I had in mind to avoid #ifdefs where possible to reduce code clutter. I wasn't aware of the planned integration with KASAN to be honest as I am not reviewing that PR and not really wrapped my head around it that much see_no_evil, but it totally makes sense 👍🏻 Nevertheless, I think it is cleaner now. Just like with the random API you can now use a common ukarch API in KASAN to use HW features if available. So at least it will make KASAN cleaner in the end smiley Thanks for making the changes 🙏🏻

Yes exactly, the moving to ukarch is not wasted, it should had been done anyway, the only part subject to changes is alloc.c, and the addition of a higher level library that would probably deploy either software or hardware memory tagging. Btw, I somehow took it also for granted that we were on the same page, then I realized that this was mostly discussed in Sinaia, sorry 😅

[craciunoiuc]

I'll go ahead and add the review tag, as we are nearing the release.

Reviewed-by: Cezar Craciunoiu cezar.craciunoiu@unikraft.io

[marcrittinghaus]

@michpappas: Just saw that you have to remove the commits from #434 (I think they are not the newest, too). We can then merge #434 first and then merge this one.

[michpappas]

Rebased from staging, and removed RNG patches. @marcrittinghaus if you're happy we can merge.

[unikraft-bot]

⚠️ Checkpatch passed with warnings

Beep boop! I ran Unikraft's checkpatch.pl support script on your pull request but it encountered warnings:

SHA	commit	checkpatch
e5e80cc	arch: Introduce the memory tagging subsystem	✅
e5d07fb	arch/arm64: Move register helpers from plat/common to arch/arm64	⚠️
1fc8acb	arch/arm64: Implement ukarch_memtag for arm64 (FEAT_MTE)	⚠️
1888bfd	lib/ukalloc: Add basic memory tagging support	✅
7d5e203	plat/kvm/arm: Enable memory tagging	✅

Truncated logs starting from first warning e5d07fb:

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#58: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:301:
+static inline uint8_t ioreg_read8(const volatile uint8_t *address)

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#66: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:309:
+static inline uint16_t ioreg_read16(const volatile uint16_t *address)

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#74: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:317:
+static inline uint32_t ioreg_read32(const volatile uint32_t *address)

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#82: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:325:
+static inline uint64_t ioreg_read64(const volatile uint64_t *address)

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#90: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:333:
+static inline void ioreg_write8(const volatile uint8_t *address, uint8_t value)

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#95: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:338:
+static inline void ioreg_write16(const volatile uint16_t *address,

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#101: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:344:
+static inline void ioreg_write32(const volatile uint32_t *address,

WARNING:VOLATILE: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#107: FILE: arch/arm/arm64/include/uk/asm/lcpu.h:350:
+static inline void ioreg_write64(const volatile uint64_t *address,

total: 0 errors, 8 warnings, 194 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

/tmp/build/a53d4c5b/patches/0002-arch-arm64-Move-register-helpers-from-plat-common-to.patch has style problems, please review.

NOTE: Ignored message types: ASSIGN_IN_IF FILE_PATH_CHANGES NEW_TYPEDEFS OBSOLETE

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

---

View complete logs | Learn more about Unikraft's coding style and contribution guidelines.

[marcrittinghaus]

Thanks @michpappas!

Approved-by: Marc Rittinghaus marc.rittinghaus@unikraft.io