In case someone is curious about how the 48-bit virtual space is split here is good info - https://wiki.osdev.org/Page_Tables#Long_mode_(64-bit)_page_m...

That's for amd64/x86_64. macOS, iOS, and recently Android on ARM64 use 16KB pages. Though, Windows does seem to use 4KB pages: https://devblogs.microsoft.com/oldnewthing/20210510-00/?p=10...

Huh. It'd never occured to me that Alpha/AXP was the only NT port that doesn't use 4KB pages (EDIT: and Itanium...). That's interesting -- I wonder how they dealt with that, especially with 16/32-bit x86 emulation (fx!32, good enough that it runs ClassiCube and Half-Life), and the dot net port that never saw the light of day, but was evidently worked on (there's still evidence of the AXP64 port in the open source dotnet, and evidence for an AXP port floating around elsewhere on GitHub...)

I know on PowerPC, with 64KB pages, IBM (?) added the subpage_prot syscall to Linux for emulation of 4KB pages, for the sake of their x86 emulation software.

Really, it's weird that NT apparently has/had some architectural support for larger pages, and then never used it again...

There is one paragraph showing when 4kb pages are used, and 4 level deep directories. (PML4 -> PDP ->

"The need for memory safety standards" (2025-02) https://news.ycombinator.com/item?id=43189934 :

> Technologies like ARM's Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture offer a complementary defense, particularly for existing code.

From OP: https://www.preludesecurity.com/blog/windows-arm64-internals... :

> In addition, current-generation ARM64 Microsoft devices, like the Surface Pro, are not shipped with chips that can support the Memory Tagging Extension (MTE) feature. Although not implemented today on Windows systems, the implementation of both PAC and MTE in the future would serve to greatly increase the cost of memory corruption exploits.

"The Arm64 memory tagging extension in Linux" (2020) on LWN: https://news.ycombinator.com/item?id=24824378#24829160

ASan: AddressSanitizer

MSan: MemSan: MemorySanitizer

Google/sanitizers is archived because it was merged into LLVM sanitizers. https://github.com/google/sanitizers/ :

> The Sanitizers project, which includes AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer, and more, is now archived.

LLVM Clang docs > AddressSanitizer: https://clang.llvm.org/docs/AddressSanitizer.html

There's a google/sanitizers wiki page from 2019 about Stack Instrumentation with ARM MTE Memory Tagging Extensions: https://github.com/google/sanitizers/wiki/Stack-instrumentat...

/? MemTagSanitizer https://www.google.com/search?q=MemTagSanitizer

"Color My World: Deterministic Tagging for Memory Safety" (2022) https://arxiv.org/abs/2204.03781 :

> 7.3 Pointer-safe tagging: Recall that safe allocations could still allow inter-object cor- ruption unless it is also pointer-safe (Sections 5.3 and 6.3). To distinguish such safe, but pointer-unsafe allocations, we tag them using the 0b10xx. Consequently, we can at run-time distinguish pointers loaded from pointer-safe allocations, and apply tag forgery prevention to all other loaded pointers.

LLVM Clang docs > MemSanitizer: https://llvm.org/docs/MemTagSanitizer.html :

> Introduction: Note: this page describes a tool under development. Part of this functionality is planned but not implemented. Hardware capable of running MemTagSanitizer does not exist as of Oct 2019.

> MemTagSanitizer is a fast memory error detector and a code hardening tool based on the Armv8.5-A Memory Tagging Extension. It detects a similar class of errors as AddressSanitizer or HardwareAssistedAddressSanitizer, but with much lower overhead.

> MemTagSanitizer overhead is expected to be in low single digits, both CPU and memory. There are plans for a debug mode with slightly higher memory overhead and better diagnostics. The primary use case of MemTagSanitizer is code hardening in production binaries, where it is expected to be a strong mitigation for both stack and heap-based memory bugs.

   -fsanitize=memtag

Code sanitizer: https://en.wikipedia.org/wiki/Code_sanitizer

   -fsanitize

Does -fsanitize=memtag already work with RISC-V CHERI?

https://github.com/CHERI-Alliance/llvm-project :

> Codasip LLVM compiler can be checked out from the codasip-cheri-riscv branch

/? "codasip-cheri-riscv" llvm https://www.google.com/search?q=%22codasip-cheri-riscv%22+ll...

codasip-cheri-riscv fork of LLVM: https://github.com/CHERI-Alliance/llvm-project/tree/codasip-...

What is the command to diff this against the commit of LLVM that it was forked from and against the LLVM main branch?

Links to the source for ARM MTE support in the LLVM / LLDB -fsanitize=memtag sanitizer:

lldb/source/Plugins/Process/Utility/MemoryTagManagerAArch64MTE.cpp : https://github.com/llvm/llvm-project/blob/main/lldb/source/P...

lldb/source/Target/MemoryTagMap.cpp: https://github.com/llvm/llvm-project/blob/main/lldb/source/T... , lldb/unittests/Target/MemoryTagMapTest.cpp: https://github.com/llvm/llvm-project/blob/main/lldb/unittest...

lldb/test/API/linux/aarch64/mte_*: https://github.com/llvm/llvm-project/tree/main/lldb/test/API...

clang/test/Driver/aarch64-mte.c: https://github.com/llvm/llvm-project/blob/main/clang/test/Dr...

clang/unittests/Driver/SanitizerArgsTest.cpp looks thin: https://github.com/llvm/llvm-project/blob/main/clang/unittes...

SanitizerArgs.cpp: https://github.com/llvm/llvm-project/blob/main/clang/lib/Dri...

llvm/docs/MemTagSanitizer.rst: https://github.com/llvm/llvm-project/blob/main/llvm/docs/Mem... :

  -fsanitize=memtag
  -fsanitize-memtag-mode=
  -f[no-]sanitize-memory-track-origins[=level]
  
  -march=armv8+memtag

LLVM docs > MemTagSanitizer > Heap Tagging: https://llvm.org/docs/MemTagSanitizer.html#heap-tagging :

> Heap Tagging: Note: this part is not implemented as of Oct 2019.

> MemTagSanitizer will use Scudo Hardened Allocator with additional code to update memory tags when

LLVM docs > Scudo Hardened Allocator: https://llvm.org/docs/ScudoHardenedAllocator.html :

> The Scudo Hardened Allocator is a user-mode allocator, originally based on LLVM Sanitizers’ CombinedAllocator. It aims at providing additional mitigation against heap based vulnerabilities, while maintaining good performance. Scudo is currently the default allocator in Fuchsia, and in Android since Android 11

compiler-rt/lib/scudo/standalone: https://github.com/llvm/llvm-project/tree/main/compiler-rt/l...

hardened_malloc is an alternative to scudo.