This is an archive of the discontinued LLVM Phabricator instance.

design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer
ClosedPublic

Authored by kcc on Nov 28 2017, 10:15 AM.

Details

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.

Diff Detail

Event Timeline

kcc created this revision.Nov 28 2017, 10:15 AM
kcc updated this revision to Diff 124604.Nov 28 2017, 10:22 AM

minor edit (explained shadow)

eugenis added inline comments.Nov 28 2017, 1:30 PM
docs/TaggedAddressSanitizerDesign.rst
2 ↗(On Diff #124604)

I vote for HardwareAssistedAddressSanitizer, or hwasan.

24 ↗(On Diff #124604)

remove "the"

101 ↗(On Diff #124604)

Mention the system calls problem with tagged pointers.

kcc updated this revision to Diff 124637.Nov 28 2017, 1:48 PM

addressed comments

kcc marked an inline comment as done.Nov 28 2017, 1:50 PM
kcc added inline comments.
docs/TaggedAddressSanitizerDesign.rst
2 ↗(On Diff #124604)

Added hwasan as an alternative.
I dislike it less then tasan.
Let's wait for other suggestions before renaming.

101 ↗(On Diff #124604)

added

May require changes in the OS kernels (e.g. Linux seems to dislike
 tagged pointers passed from address space).
davidxl added inline comments.
docs/TaggedAddressSanitizerDesign.rst
22 ↗(On Diff #124637)

What is the overhead of redzones compared with shadow memory?

49 ↗(On Diff #124637)

a real runtime call or it will be lowered into inline sequence?

kcc added inline comments.Nov 28 2017, 5:36 PM
docs/TaggedAddressSanitizerDesign.rst
22 ↗(On Diff #124637)

depends.
shadow is 1/9 of all memory.
redzones largely depend on the allocation patterns.
If most heap allocations are big, the combined redzones are tiny, and vise versa

49 ↗(On Diff #124637)

at least in the initial implementation -- yes.
Since this is aarc64-specific, the call/ret should be relatively cheap.
But of course nothing prevents us from inlining if we see a need for it.

kcc updated this revision to Diff 124691.Nov 28 2017, 8:17 PM

mention alternatives for memory access instrumentation

eugenis added inline comments.Nov 29 2017, 11:44 AM
docs/TaggedAddressSanitizerDesign.rst
22 ↗(On Diff #124637)

It's worth mentioning that typical ASan memory overhead of 2x to 3x, mainly from redzones and quarantine.

This new tool will have only the shadow, which is a tiny fraction of the original memory footprint, and some overhead from over-aligning everything. The latter is expected to be small, especially if N (see below) is reduced to 16 or even 8, in which case the shadow grows to 1/16th or 1/8th, respectively. In any case, I'd expect less than 25% RAM overhead, hopefully way less.

kcc updated this revision to Diff 124797.Nov 29 2017, 11:49 AM

rephrase the sources of asan overhead

kcc marked an inline comment as done.Nov 29 2017, 11:49 AM
kcc updated this revision to Diff 125045.Nov 30 2017, 3:34 PM

Rename the new tool to HWASAN

eugenis accepted this revision.Dec 1 2017, 4:00 PM

Looks great!

This revision is now accepted and ready to land.Dec 1 2017, 4:00 PM
This revision was automatically updated to reflect the committed changes.