This is an archive of the discontinued LLVM Phabricator instance.

hwasan: Improve precision of checks using short granule tags.
ClosedPublic

Authored by pcc on Jun 27 2019, 5:14 PM.

Details

Summary

A short granule is a granule of size between 1 and TG-1 bytes. The size
of a short granule is stored at the location in shadow memory where the
granule's tag is normally stored, while the granule's actual tag is stored
in the last byte of the granule. This means that in order to verify that a
pointer tag matches a memory tag, HWASAN must check for two possibilities:

  • the pointer tag is equal to the memory tag in shadow memory, or
  • the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule.

Pointer tags between 1 to TG-1 are possible and are as likely as any other
tag. This means that these tags in memory have two interpretations: the full
tag interpretation (where the pointer tag is between 1 and TG-1 and the
last byte of the granule is ordinary data) and the short tag interpretation
(where the pointer tag is stored in the granule).

When HWASAN detects an error near a memory tag between 1 and TG-1, it
will show both the memory tag and the last byte of the granule. Currently,
it is up to the user to disambiguate the two possibilities.

Because this functionality obsoletes the right aligned heap feature of
the HWASAN memory allocator (and because we can no longer easily test
it), the feature is removed.

Also update the documentation to cover both short granule tags and
outlined checks.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jun 27 2019, 5:14 PM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptJun 27 2019, 5:15 PM
Herald added subscribers: Restricted Project, cfe-commits, jfb and 3 others. · View Herald Transcript
pcc updated this revision to Diff 207379.Jul 1 2019, 10:58 AM
  • Simplify tagAlloca
eugenis added inline comments.Jul 3 2019, 5:21 PM
compiler-rt/lib/hwasan/hwasan_allocator.cpp
159 ↗(On Diff #207379)

When !(flags()->tag_in_malloc && malloc_bisect(stack, orig_size)), the tail tag should be 0 as well.

compiler-rt/lib/hwasan/hwasan_checks.h
69 ↗(On Diff #207379)

s/15/kShadowAlignment -1/

113 ↗(On Diff #207379)

0xfull, nice :)
A named constant please.

llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
1195 ↗(On Diff #207379)

Good. I think we will need to do the same in MTE patches, but for different reason.

There is something in BasicAA that thinks that a store of size 16 (in MachineInstr) can not possibly alias with a smaller alloca, so simply increasing alloca alignment is not enough.

pcc updated this revision to Diff 208758.Jul 9 2019, 11:32 AM
pcc marked 3 inline comments as done.
  • Address review comments
compiler-rt/lib/hwasan/hwasan_allocator.cpp
159 ↗(On Diff #207379)

It was already being set to 0 on line 167. You mean that the tag in shadow memory should be 0, right? Makes sense, done.

eugenis accepted this revision.Jul 9 2019, 1:07 PM

LGTM

This revision is now accepted and ready to land.Jul 9 2019, 1:07 PM
This revision was automatically updated to reflect the committed changes.
xiangzhangllvm added inline comments.
compiler-rt/trunk/lib/hwasan/hwasan_checks.h
76

Hello @pcc I think here seems some problem, the ptr is user passing point,
*(ptr + n) should have the user's real data. it shouldn't "== ptr_tag".

pcc added inline comments.Dec 21 2020, 11:53 PM
compiler-rt/trunk/lib/hwasan/hwasan_checks.h
76

If this is a short granule then from the user's perspective the maximum size of the granule is (granule size - 1). This means that the last byte of the granule is free for us to use to store the granule's real tag.

compiler-rt/trunk/test/hwasan/TestCases/heap-buffer-overflow.c