| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Differential Revision: https://reviews.llvm.org/D63908
llvm-svn: 365551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
missing a bug.
Summary: Provided rule of thumb percentage chances of miss for 4 and 8 bit tag sizes.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58195
llvm-svn: 353990
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D56946
llvm-svn: 351976
|
|
|
|
|
|
|
|
|
| |
errors on) and clean up the formattting.
This isn't actualy assembly anyways, so dropping the highlighting is
probably for the best.
llvm-svn: 338979
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To complement https://reviews.llvm.org/D45840
Reviewers: eugenis
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45996
llvm-svn: 330745
|
|
|
|
| |
llvm-svn: 327471
|
|
|
|
|
|
| |
behaviour
llvm-svn: 326373
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42874
llvm-svn: 324163
|
|
|
|
| |
llvm-svn: 321027
|
|
|
|
| |
llvm-svn: 320168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* use more readable name
* document the hwasan attribute
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D40938
llvm-svn: 320075
|
|
to AddressSanitizer
Summary:
preliminary design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer
The name TaggedAddressSanitizer and the rest of the document, are early draft, suggestions are welcome.
The code will follow shortly.
Reviewers: eugenis, alekseyshl
Reviewed By: eugenis
Subscribers: davidxl, cryptoad, fedor.sergeev, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D40568
llvm-svn: 319684
|