<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>><br>> >   static int a[8];<br>> >   static int *p = a - 5;<br>> > ...<br>> >   p[10] = 1;<br>> > should work (even if it's not valid in c it can be valid as<br>> > a c extension or written in asm, so ELF should support it).<br>><br>><br>> IMO this is exactly the kind of thing that MTE is trying to *prevent*. I<br>> don't see why we would want to support something like this.<br>sorry for the late answer, but i disagree.</blockquote><div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 2:18 AM Szabolcs Nagy <<a href="mailto:nsz@port70.net">nsz@port70.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Mitch Phillips <<a href="mailto:mitchp@google.com" target="_blank">mitchp@google.com</a>> [2020-10-09 13:17:06 -0700]:<br>
> <br>
> >   static int a[8];<br>
> >   static int *p = a - 5;<br>
> > ...<br>
> >   p[10] = 1;<br>
> > should work (even if it's not valid in c it can be valid as<br>
> > a c extension or written in asm, so ELF should support it).<br>
> <br>
> <br>
> IMO this is exactly the kind of thing that MTE is trying to *prevent*. I<br>
> don't see why we would want to support something like this.<br>
<br>
sorry for the late answer, but i disagree.<br>
<br>
the compiler can generate such code for good reasons,<br>
and it can be useful in high level program code too.<br>
<br>
mte is not for interfering with pointer arithmetics,<br>
but to check invalid memory access at load/store time<br>
if we can tie the dereferenced pointer to an object.<br>
<br>
there is no reason to assume a pointer can be always<br>
dereferenced. (and i think it's not relevant that iso<br>
c happens to allow pointers past the end of an array,<br>
even if that was forbidden, the construct should be<br>
supported in elf not to restrict code generators.)<br>
<br>
i think if the pointers cannot be tied to an object<br>
then the object must not be tagged, and if they can be<br>
then that should be represented in the relocation<br>
(so you need a symbolic relocation and object bounds<br>
for the symbol even if the symbol is not visible. i<br>
think it's also fine to have a separate object bounds<br>
table for hidden symbols and reference that instead of<br>
the symbol table, i'm not sure if this needs a new<br>
relocation type or changing relative relocs is enough)<br>
<br>
</blockquote></div>