On Mon, Aug 10, 2020 at 3:41 AM David Spickett via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi all,
>
> What follows is my proposal for supporting AArch64's memory tagging
> extension in LLDB. I think the link in the first paragraph is a good
> introduction if you haven't come across memory tagging before.
>
> I've also put the document in a Google Doc if that's easier for you to
> read:
> https://docs.google.com/document/d/13oRtTujCrWOS_2RSciYoaBPNPgxIvTF2qyOfhhUTj1U/edit?usp=sharing
> (please keep comments to this list though)
>
> Any and all comments welcome. Particularly I would like opinions on
> the naming of the commands, as this extension is AArch64 specific but
> the concept of memory tagging itself is not.
> (I've added some people on Cc who might have particular interest)
>
> Thanks,
> David Spickett.
>
>
>
> # RFC: AArch64 Linux Memory Tagging Support for LLDB
>
> ## What is memory tagging?
>
> Memory tagging is an extension added in the Armv8.5-a architecture for
> AArch64.
> It allows tagging pointers and storing those tags so that hardware can
> validate
> that a pointer matches the memory address it is trying to access. These
> paired
> tags are stored in the upper bits of the pointer (the “logical” tag) and in
> special memory in hardware (the “allocation” tag). Each tag is 4 bits in
> size.
>
>
> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety
>
> ## Definitions
>
> * memtag - This is the clang name for the extension as in
> “-march=armv8.5-a+memtag”
> * mte - An alternative name for mmtag, also the llvm backend name for
> the extension.
> This document may use memtag/memory tagging/MTE at times, they mean
> the same thing.
> * logical tag - The tag stored inside a pointer variable (accessible
> via normal shift and mask)
> * allocation tag - The tag stored in tag memory (which the hardware
> provides)
> for a particular tag granule
> * tag granule - The amount of memory that a single tag applies to,
> which is 16 bytes.
>
> ## Existing Tool Support
>
> * GCC/Clang can generate MTE instructions
> * Clang has an option to memory tag the stack (discussed later)
> * QEMU support has been merged
> * Linux Kernel patches are in progress
> (git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> “devel/mte-v5” branch)
> * GDB support is in review and this design takes a lot of direction from
> that
> (
> https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/luisgpm/aarch64-mte-v2
> )
> (originally proposed
> https://sourceware.org/pipermail/gdb-patches/2019-August/159881.html)
>
> ## New lldb features
>
> Assuming your software is acting correctly, memory tagging can “just work”
> without debugger support. This assumes the compiler/toolchain/user are
> always correct.
>
> For when that isn’t the case we want to be able to:
> * Read/write the logical tags in a pointer
> * Read/write the allocation tags assigned to a given area of memory
> * Test whether the logical tag in a pointer matches the allocation tag of
> the
> memory it refers to
> * Read/write memory even when tags are mismatched
>
> The most obvious use case for this is working through issues where bugs in
> the
> toolchain don’t generate correct code. On the other hand there’s a good
> case for
> deliberately messing with pointers in your code to prove that such
> protection
> actually works.
>
> Note: potential extensions to scripting such as tags as attributes of
> values and
> such are not being proposed here. Of course the new commands will be
> added in the
> standard ways so you can use those.
>
> ## New Commands
>
> ### Command Availability
>
> Note: commands will be listed in tab completion and help regardless of
> these checks
>
> * The remote server must support memory tagging packets. lldb will
> send/check
> for the “memory-tagging” feature in the qSupported packet. (this
> name aligns with gdb)
> * The process must have MTE available. We check HWCAP2_MTE for this.
> * The process must have enabled tagged addressing using prctl
> (see “New Registers” for details)
> * The address given must be in a range that has MTE enabled, since you can
> mmap
> with or without MTE. (this information is in /proc/.../smaps)
>
> Interaction With Clang’s Stack Tagging
>
> We’re relying on the kernel to tell us if MTE is enabled, so stack tagging
> will
> not be visible to the debugger this way.
> (
> https://github.com/google/sanitizers/wiki/Stack-instrumentation-with-ARM-Memory-Tagging-Extension-(MTE)
> )
>
> E.g. {int x; use(&x); } where x is void x(int* ptr);
> “ptr” will have a memory tag but the kernel won’t know this.
>
> To work around this a setting will be added to tell lldb to assume that
> MTE is
> enabled, so that you can at least see the logical tags of a pointer.
> (see “New Settings”)
>
> ### General Properties/Errors
>
> * must resolve to some value that can be handled as an
> address by lldb. (though it
