aarch64: Memory tagging modes proposal

[Yury Khrustalev]

Request for feedback.

This is a proposal for how MTE binary marking from [1] should co-exist with
the MTE Glibc tunable (not yet implemented). In my opinion, both are necessary
to cover all practical use cases and provide both flexibility of future
experiments and ease of configuration for developers and end users. This
explain how it all should work.

[1]: https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst

The set of rules below:

1) Respects binary marking when it's present.
2) Tunable cannot disable tagging, only change MTE mode.
3) What kind of memory tagging is enabled (i.e. the scope) is solely
   determined either by the binary marking (when it's present) or by
   the tunable (when marking is not present).
4) You cannot enable stack and globals tagging unless corresponding
   binary marking is present (it requires support by compiler and static
   linker), but you can choose if you enable heap tagging for unmarked
   binaries.
5) If you want heap tagging for marked binaries, the DT_AARCH64_MEMTAG_HEAP
   tag must be set explicitly.

Binary marking:
 - DT_AARCH64_MEMTAG_MODE=0|1: selects fault mode for MTE memory tag
   checking, i.e. MTE mode.
 - DT_AARCH64_MEMTAG_{HEAP,STACK,GLOBALS} determines the scope of
   memory tagging.

Tunable:
 - glibc.cpu.mtemode=none|auto|sync|async: selects fault mode for MTE
   memory tag checking (also see below), default value is 'none'.

If both the tunable and the DT_AARCH64_MEMTAG_MODE tag are explicitly
set, the tunable takes precedence (allows to override mode that is built
into the binary) except when tunable is set to 'none' in which case the
tunable has no effect.

Tunable cannot disable MTE memory tagging when binary marking requires it,
it can only change the mode.

If none of DT_AARCH64_MEMTAG_{HEAP,STACK,GLOBALS} is present, the tunable,
when set to a value other than 'none', will enable the "standard" set of
memory tagging features (currently HEAP).

If DT_AARCH64_MEMTAG_MODE is not present and the mode has to be inferred
from the binary marking (i.e. in the absence of the tunable), the default
value for the mode is 'auto'.

 1) No binary marking: when none of the DT_AARCH64_MEMTAG_{HEAP,STACK,GLOBALS}
    tags are present:

  | Tunable | MEMTAG_MODE | Status | Mode  | Scope     |
  |----------------------------------------------------|
  | (unset) | (ignored)   | off    |  --   | --        |
  | none    | (ignored)   | off    |  --   | --        |
  | auto    | (ignored)   | on     | auto  | standard  |
  | sync    | (ignored)   | on     | sync  | standard  |
  | async   | (ignored)   | on     | async | standard  |

 2) When DT_AARCH64_MEMTAG_{HEAP,STACK,GLOBALS} are present (at least
    one of them):

  | Tunable | MEMTAG_MODE | Status | Mode  | Scope     |
  |----------------------------------------------------|
  | (unset) | (unset)     | on     | auto  | (marking) |
  | (unset) | 0           | on     | sync  | (marking) |
  | (unset) | 1           | on     | async | (marking) |
  | none    | (unset)     | on     | auto  | (marking) |
  | none    | 0           | on     | sync  | (marking) |
  | none    | 1           | on     | async | (marking) |
  | auto    | (ignored)   | on     | auto  | (marking) |
  | sync    | (ignored)   | on     | sync  | (marking) |
  | async   | (ignored)   | on     | async | (marking) |

In the table above, '(marking)' means whatever components are flagged with
the DT_AARCH64_MEMTAG_{HEAP,STACK,GLOBALS} tags and are supported by the
current version of Glibc.

Status 'on' means that the prctl(PR_TAGGED_ADDR_ENABLE) will be made at the
start of the process. The mode is included in the flags for this syscall.

The Scope determines which parts of the tagging implementation in Glibc
are actually activated.

This may appear complicated however this is due to the difference of how
heap tagging is implemented compared to tagging of stack and globals. In
the latter case binary needs to be built with necessary instrumentation
that is not controlled by Glibc.

Any feedback welcome!

Thanks,
Yury