[PATCH 0/7] RFC Memory tagging support

[H.J. Lu]

On Tue, Jun 16, 2020 at 1:14 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> 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).

MTE isn't just another debugging tool.  Otherwise, we wouldn't
want it in glibc.   Since we are enabling MTE in some object files,
at least we should mark them as MTE enabled.

> i think a marking design for heap tagging has to at
> least consider:
>
> 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.

MTE marker can be in the GNU_PROPERTY segment.

> 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).

How to use the MTE marker info is up to the runtime.

> 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.

This sounds like

GLIBC_TUNABLES=glibc.cpu.x86_shstk=on

> 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".

It sounds like IBT and SHSTK in CET.

> do you think such static marking design can be

I think we should do it now.

> 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)

Compiler should try to detect it, like -Wstringop-overflow.
Initially compilers can add a marker only via a command-line
option.

-- 
H.J.