[PATCH 0/7] RFC Memory tagging support
Tue Jun 16 08:14:25 GMT 2020
The 06/15/2020 12:18, H.J. Lu wrote:
> I think we need a marker to indicate an object is MTE compatible.
i expect users to only able to discover tag-unsafety
issues in applications at runtime and even if there
is static information in binaries that's usually too
late to do anything useful about it (other than fail).
so i think an initial implementation that is off by
default but can be turned on with an env var makes
sense, but i agree that to turn tagging on by default
some markings will be needed such that tag-unsafe
applications continue to work (if possible).
i think a marking design for heap tagging has to at
1 malloc can be interposed and then tagging is not a
libc internal decision. so i think we would have to
expose the markings to user code (e.g. like hwcaps)
or have an opt-in libc api for malloc implementors
to request tagging which can fail in the presence
of unmarked modules.
2 software components other than malloc may choose
to use tagging on memory that they manage: tagging
can be controlled per page on aarch64, the only
global settings are: enable syscall abi to take
tagged pointers, select the tag checking behaviour
(e.g. SIGSEGV on mismatch) and select the behaviour
of the random tag generator instruction. The global
settings may need coordination, but the ability to
use tagging (locally) should not be disabled based
on markings (of other modules).
3 users will want to force the tagging on at runtime
even if their code is not tagging safe: this can
be used for debugging unmodified binaries, and
hitting a tagging issue is a dynamic property not
statically determined, i.e. using tagging with
code that's not generally tagging safe may work.
the nice thing about heap tagging is that it's a
runtime decision, no recompilation is needed, we
should not ruin this.
4 there is tag-unsafe code that makes assumptions
about pointer representation (e.g. stores things in
the top bits of pointers) passing tagged pointers
to such a module does not work with whatever tag
checking setting, but there is tag-unsafe code that
makes assumptions about the granularity of memory
protection (e.g. assumes out of bound read is ok if
it does not cross a page boundary) which is fine
with tagged pointers, it just does not want to fault
(e.g. tag checking can have a monitoring mode where
tag mismatch is counted by the kernel per process
and not cause runtime behaviour changes), so if we
have markings then we need different marking for
"compatible with tagged pointers" and "compatible
with faulting tag checking mode".
do you think such static marking design can be
introduced later? what should the compiler do?
(in principle a compiler can generte tag-unsafe code
for conforming c code currently, but that's unlikely,
it's much more likely that the source code is doing
something non-portable, but that's hard to find out
in the compiler)
More information about the Libc-alpha