[compiler-rt][hwasan] Add __hwasan_library_loaded/unloaded to hwasan_interface.h

[leonardchan]

Summary

These are interface functions because a platform that supports instrumenting globals needs a dynamic loader to call these to register globals correctly.

[vitalybuka]

we will probably search for a different solution with glibc

[vitalybuka]

BTW, @mcgrathr, any hints what can be done for GLIBC, taking into account that we likely need to support older versions.

[mcgrathr]

For the general case, not only glibc but probably all preexisting system libraries that don't have special hwasan support built in, I don't think you can rely on anything to hook into here. If you really needed to, *maybe* you could have dlopen and dlclose interceptors, but that seems really unlikely to go well. Bottom line, you probably have to find a way on those systems to have vanilla init and fini hook behavior (init_array, preinit_array, fini_array, etc.) be sufficient. It's challenging because you really need to come in before any code that could access a global is run, and with a DSO overriding a symbol in one of its DT_NEEDED DSOs the order of init hooks getting called could make it impossible to be in the right place.

So you might actually need to resort to essentially a dl_iterate_phdr-based check (using the dlpi_adds/dlpi_subs counts to optimize unnecessary re-checks) eagerly done after dlclose. And for dlopen you might actually be SOL unless you can do something with the LD_AUDIT interface. Yeah, that's probably what you have to do, but it's going to be pretty painful. It's probably not feasible without the hwasan runtime being a DSO itself, unless you do some really nasty stuff in the compiler driver to fudge link switches. The DSO or executable needs to have a DT_AUDIT for a separate special DSO that will get callbacks. LLD doesn't even support the switches to create that entry, so there's a lot to make all that happen. Not to mention it's a DSO load, so it has all the RUNPATH requirements of any other DSO. It's a lot.

compiler-rt/include/sanitizer/hwasan_interface.h

46

I suspected that one of the reasons this wasn't exposed originally is because it's ELF-specific (and as written here, even specific to the GNU spellings like ElfW).

Even if it has only been supported for GNU-compatible ELF platforms so far, there's no reason hwasan shouldn't eventually support non-ELF systems or non-GNU ELF systems where this signature or spelling thereof is problematic.

EllfW(Addr) here has no particular value and you could as well just use uintptr_t.
Likewise, ElfW(Half) is just uint16_t (in all variants of ELF) and there's no particular value to passing it with that type instead of something more usual like size_t.. In fact, using Half/uint16_t here breaks some cases that can otherwise work in theory (PN_XNUM cases).

It might be safest to make the phdr argument just const void* and just comment that this is used as an array of ELF Phdr structs. Then you don't need to rely on <link.h> at all.

51

Both of these, but especially the unloaded hook, need to specify clearly when they need to be called relative to other aspects of loading/unloading like relocation, init hooks, and unmapping. I think the requirements are:

• loaded: After the module has been fully loaded and relocated, but before any of its code (e.g. initializers) has run.
• unloaded: After the module's code will no longer be run, and either before or after its segments have been unmapped.

But we should verify and make the specified constraints precise. (For example it's important for the implementation to know whether the unloaded hook *requires* that the code already be unmapped, or doesn't care either way. One reason for this is that ordinarily the phdr array may well be part of what gets unmapped, so if this said it should be called after unmapping, the implementation would have to do extra gymnastics.)

[leonardchan]

Updated the function signatures. Also updated comments to make them less ELF-specific.

compiler-rt/include/sanitizer/hwasan_interface.h

51

Updated with comments adding restrictions. I think the loaded restrictions are more straightforward. For unloaded, I just put must be called *before* unmapping. Unloading before seems more straightforward to me and I think this is what all current users of this function do anyway. I also can't think of a reason for why it would be desirable to unload after unmapping. I imagine if we explicitly say "before" right now, we won't lose anything if we decide to say "before or after" later. @vitalybuka Thoughts?

compiler-rt/include/sanitizer/hwasan_interface.h

#endif
   // Mark region of memory with the given tag. Both address and size need to be
   // 16-byte aligned.
   void __hwasan_tag_memory(const volatile void *p, unsigned char tag,
                            size_t size);
 
   /// Set pointer tag. Previous tag is lost.
   void *__hwasan_tag_pointer(const volatile void *p, unsigned char tag);
 
+  // Register/unregister globals in a loaded module. The dynamic loader is
+  // required to call these when loading/unloading a module to prevent false
+  // positives from accesses to interposable globals in module constructors.
+  //
+  // In particular, the loaded hook needs to be called:
+  // - After the module has been fully loaded
+  // - After relocations have been resolved
+  // - Before module constructors have been run
+  //
+  void __hwasan_library_loaded(uintptr_t base, const void *phdr,
+                               size_t phnum);
+
+  // The unloaded hook needs to be called:
+  // - After the module's code will no longer run (which also means after
+  //   destructors)
+  // - Before the module's segments have been unmapped.
+  //
+  void __hwasan_library_unloaded(uintptr_t base, const void *phdr,
+                                 size_t phnum);
+
   // Set memory tag from the current SP address to the given address to zero.
   // This is meant to annotate longjmp and other non-local jumps.
   // This function needs to know the (almost) exact destination frame address;
   // clearing shadow for the entire thread stack like __asan_handle_no_return
   // does would cause false reports.
   void __hwasan_handle_longjmp(const void *sp_dst);
 
   // Set memory tag for the part of the current thread stack below sp_dst to