leonardchan added a comment. In D132425#3752468 <https://reviews.llvm.org/D132425#3752468>, @hctim wrote:
> Glad to see that refactoring the sanitizer metadata made someone's life > easier ;) (now allowing for disabling hwasanificiation of globals) > > Patch looks reasonable to me. Can you please add the negative test (that > vtables under the vanilla ABI still have hwasan)? Yup. Will add a followup patch. > I wans't fully aware of the relative vtables ABI, and it may have some > implications about MTE globals tagging (draft abi > <https://github.com/ARM-software/abi-aa/blob/c52c9da1e4e4bec2a469499db5f175161142ea00/memtagabielf64/memtagabielf64.rst#tagging-global-variables>). > Because logical tags are synthesized at runtime into a synthetic GOT entry - > dynamic relocations I believe would be forced (removing any benefit of the > relative vtables ABI), so for now it seems like MTE globals and relative > vtables are mutually exclusive. Another option would be to disable MTE > globals for relative vtables as well. No action needed on your part, just > putting some wordso n paper that this might need some consideration at a > later date if Fuchsia wants to support MTE globals. Thanks for bringing this up. For relative vtables, the important bit is that the vtable is populated with statically known offsets between the vtable and its virtual functions. The particular linker error this patch resolves occurs because the hwasan pass happens to replace references to the vtable (within the vtable) with the alias, so the tag causes an overflow when resolving the relocation. Now if I'm understanding the draft correctly, the way MTE will work with globals is that all references to globals *must* go through the GOT because the dynamic linker will place the tagged address there, so the potential conflict with relative vtables is that we wouldn't know the full tagged address of the vtable at link time, hence the dynamic relocation. If so, simply disabling MTE on relative vtables would also be a short term solution. We have a generic long term solution for hwasan+RV which I think might also be applicable for MTE+RV. For hwasan, since it's mainly the IR pass that converts usages of the vtable (within the vtable itself) to use tagged aliases, the ideal solution is to just have hwasan ignore these specific references in the vtable such that offset calculation can continue to use the untagged address allowing the relocation arithmetic to not overflow. Now for llvm, I'm assuming it's an instrumentation pass like memtagsanitizer that will ensure all references to globals go through the GOT by replacing all global references with the appropriate IR that gets lowered to this GOT reference. If this is the case, then I *think* a similar solution can be done here where particular references to the vtable continue to use the original vtable address and avoid instrumentation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132425/new/ https://reviews.llvm.org/D132425 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
