llvm dev - Jul 2020 - [MTE] Tagging Globals

Not at this stage -- no.

On Wed, Jul 15, 2020 at 3:23 PM Zhaoshi Zheng <zhaoshiz at quicinc.com>
wrote:
> Mitch,
>
>
>
> I forgot to ask: do you have any timeline on sharing it through
> Phabricator?
>
>
>
> Thanks,
>
> Zhaoshi
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Zhaoshi
> Zheng via llvm-dev
> *Sent:* Tuesday, July 14, 2020 21:34
> *To:* Mitch Phillips <mitchp at google.com>
> *Cc:* llvm-dev at lists.llvm.org; Stephen Long <steplong at
quicinc.com>
> *Subject:* [EXT] Re: [llvm-dev] [MTE] Tagging Globals
>
>
>
> Thanks for the update, Phillips.
>
>
>
> Yes, please add me, Stephen and Ana (CCed) to Phabricator reviews.
>
>
>
> Zhaoshi
>
>
>
> *From:* Mitch Phillips <mitchp at google.com>
> *Sent:* Tuesday, July 14, 2020 19:10
> *To:* Zhaoshi Zheng <zhaoshiz at quicinc.com>
> *Cc:* llvm-dev at lists.llvm.org; Stephen Long <steplong at
quicinc.com>
> *Subject:* [EXT] Re: [llvm-dev] [MTE] Tagging Globals
>
>
>
> Hi Zhaoshi,
>
>
>
> Currently there's no global tagging instrumentation for MTE. We have a
> good idea about the implementation's design - but no patches are ready
to
> be shared at this stage.
>
>
>
> If you'd like - I'd be more than happy to CC yourself and Stephen
on any
> Phabricator reviews :).
>
>
>
> On Tue, Jul 14, 2020 at 5:04 PM Zhaoshi Zheng via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
>
>
> We’re evaluating memory tagging (MTE) on some internal workloads.
>
>
>
> We noticed that stack variables are tagged by an instrumentation pass and
> heap objects are handled by the allocator (Scudo).
>
>
>
> How about global variables? We tried a simple case using
> -march=armv8a+memtag -fsanitize=memtag, but found no tagging:
>
>
>
> Are we missing anything or tagging globals is still in progress?
>
>
>
> *int global_array[16];*
>
>
>
> *int main(int argc, char **argv) {*
>
> *  global_array[1] = 0;*
>
> *  return global_array[argc + 16];  // BOOM*
>
> *}*
>
>
>
> clang++ -O1 --target=aarch64-linux -march=armv8.5a+memtag
> -fsanitize=memtag test.cpp -S -o test.s
>
>
>
> *main:                                   // @main*
>
> *.Lmain$local:*
>
> *// %bb.0:                               // %entry*
>
> *        adrp    x8, global_array*
>
> *        add     x8, x8, :lo12:global_array*
>
> *        str     wzr, [x8, #4]*
>
> *        add     x8, x8, w0, sxtw #2*
>
> *        ldr     w0, [x8, #64]*
>
> *        ret*
>
> *.Lfunc_end0:*
>
> *        .size   main, .Lfunc_end0-main*
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200715/8ec3ca78/attachment.html>

On 16/07/2020 00:36, Mitch Phillips via llvm-dev wrote:
> Not at this stage -- no.
We'd also be interested in participating in this discussion.  For CHERI, 
we had to define relocations for initialising pointers that had to 
understand something about the object that they were pointing to.  There 
is probably some commonality in the requirements here.

David

Sure.

An outline: We're thinking of a relocation-based approach, where all
non-const global references (including globals with hidden visibility) are
through the GOT. The relocation would be an extension to GLOB_DAT, with the
addition that the dynamic loader is responsible for creating a random tag
and inserting it into the GOT entry.

For MTE, the only data we need to know at load time is the size of the
global, which would be encoded in the relocation addend.

There is a performance cost of indirecting through the GOT - but that's the
price of having fully dynamic tags.

On Thu, Jul 16, 2020 at 2:58 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 16/07/2020 00:36, Mitch Phillips via llvm-dev wrote:
> > Not at this stage -- no.
>
> We'd also be interested in participating in this discussion.  For
CHERI,
> we had to define relocations for initialising pointers that had to
> understand something about the object that they were pointing to.  There
> is probably some commonality in the requirements here.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/58e32ad2/attachment.html>