[llvm-dev] [MTE] Globals Tagging - Discussion

[Mitch Phillips via llvm-dev]

>
>
> >
> > >   static int a[8];
> > >   static int *p = a - 5;
> > > ...
> > >   p[10] = 1;
> > > should work (even if it's not valid in c it can be valid as
> > > a c extension or written in asm, so ELF should support it).
> >
> >
> > IMO this is exactly the kind of thing that MTE is trying to *prevent*. I
> > don't see why we would want to support something like this.
> sorry for the late answer, but i disagree.


No problem :). I also disagree with myself. In this example, the
TAGGED_RELATIVE relocation for `p` contains an r_addend of `a`, meaning
that the tag for `p` should be derived from `a`, not randomised. So if `a`
has a memory tag of `0xf`, then `p` will also have a memory tag of `0xf`.
Does this allay your fears?

On Tue, Nov 10, 2020 at 2:18 AM Szabolcs Nagy <nsz at port70.net> wrote:

> * Mitch Phillips <mitchp at google.com> [2020-10-09 13:17:06 -0700]:
> >
> > >   static int a[8];
> > >   static int *p = a - 5;
> > > ...
> > >   p[10] = 1;
> > > should work (even if it's not valid in c it can be valid as
> > > a c extension or written in asm, so ELF should support it).
> >
> >
> > IMO this is exactly the kind of thing that MTE is trying to *prevent*. I
> > don't see why we would want to support something like this.
>
> sorry for the late answer, but i disagree.
>
> the compiler can generate such code for good reasons,
> and it can be useful in high level program code too.
>
> mte is not for interfering with pointer arithmetics,
> but to check invalid memory access at load/store time
> if we can tie the dereferenced pointer to an object.
>
> there is no reason to assume a pointer can be always
> dereferenced. (and i think it's not relevant that iso
> c happens to allow pointers past the end of an array,
> even if that was forbidden, the construct should be
> supported in elf not to restrict code generators.)
>
> i think if the pointers cannot be tied to an object
> then the object must not be tagged, and if they can be
> then that should be represented in the relocation
> (so you need a symbolic relocation and object bounds
> for the symbol even if the symbol is not visible. i
> think it's also fine to have a separate object bounds
> table for hidden symbols and reference that instead of
> the symbol table, i'm not sure if this needs a new
> relocation type or changing relative relocs is enough)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201110/d53220e7/attachment.html>