[all-commits] [llvm/llvm-project] 9854cd: [test][HWASAN] Test for globals with short granules

[Mitch Phillips via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9854cddf95256a20e298954c5c0bf8c01147955b
      https://github.com/llvm/llvm-project/commit/9854cddf95256a20e298954c5c0bf8c01147955b
  Author: Vitaly Buka <vitalybuka at google.com>
  Date:   2023-05-18 (Thu, 18 May 2023)

  Changed paths:
    A llvm/test/Instrumentation/HWAddressSanitizer/globals-tag.ll

  Log Message:
  -----------
  [test][HWASAN] Test for globals with short granules


  Commit: 8f061edef83991f41508a19961e833404dfb17f6
      https://github.com/llvm/llvm-project/commit/8f061edef83991f41508a19961e833404dfb17f6
  Author: Mitch Phillips <31459023+hctim at users.noreply.github.com>
  Date:   2023-05-18 (Thu, 18 May 2023)

  Changed paths:
    M llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
    M llvm/test/Instrumentation/HWAddressSanitizer/X86/globals.ll
    M llvm/test/Instrumentation/HWAddressSanitizer/globals-tag.ll

  Log Message:
  -----------
  [HWASan] Ignore shortgranules for global tag selection

Tag selection for global variables is sequential, starting at a
pseduo-ish seed that's based on the hash of the file name.

Previously, it was possible for a global to be assigned a tag in the
range [1,15]. If the global's size was not a multiple of granules (i.e.
`size % 16 != 0`), then the last granule of the global would be assigned
a short granule tag as well.

If the real memory tag of the global (e.g. '04') happened to collide
with the short granule tag (e.g. '04'), then __hwasan_check would
see that the memory tag matched the short granule tag, and dutifully
assume (in this fast check) that everthing is okay.

Unfortunately, if you tried to access the [5,15]th byte, you never get
to the short granule check. This means you miss intra-granule overflows
on the last granule of a global, if said global was assigned a real
memory tag in the range [1,15].

This causes flakiness in certain global tests, if the SHA of the
filename changes between runs.

This problem also exists for heap and stack allocations as well, but
there's a concern that if we exclude the [1,15] range for heap and stack
that it's an unhappy tradeoff. On Android, this would mean that a 1/255
chance of false positive becomes 1/240. On other platforms though (that
have a less-than-8-bit tag space), this may be unacceptable. We can
think about potential fixes for that in other places, but globals are
fine to reduce the space, as really the only thing that matters is
catching sequential overflow. The false-negative scenario is much, much
more common in use-after-free and use-after-scope, which globals don't
have.

Differential Revision: https://reviews.llvm.org/D150742


Compare: https://github.com/llvm/llvm-project/compare/b7bdf1996fd1...8f061edef839