This is an archive of the discontinued LLVM Phabricator instance.

Handle libhwasan system allocator fallback during thread initialisation
AbandonedPublic

Authored by mmalcomson on Oct 16 2019, 9:30 AM.

Details

Reviewers
eugenis
kcc
pcc
Group Reviewers
Restricted Project
Summary

The system allocator fallback added in https://reviews.llvm.org/D55986
(llvm-svn: 350427) introduces the assumption that all allocations with a zero
tag have been allocated by the system allocator.

During thread initialisation this assumption no longer holds.
Thread::Init disables tagging using the ScopedTaggingDisabler, until its
internal data structures have been initialised so that
Thread::GenerateRandomTag can generate a random tag.

While libhwasan finds the stack bounds using pthread attributes, libc allocates
and frees an object at the time that stack tagging is disabled. Hence the
allocation is handled by libhwasan and the free is given to the system
allocator.

I have attached a patch here that makes the hwasan allocation routine pass
allocation off to the system allocator if tagging is disabled in the current
thread.

Another approach I considered was to make GenerateRandomTag return a known
non-zero tag when tagging is disabled for the current thread.
I decided against this since the tags of other pointers seem to be zero when
tagging is disabled (e.g. for flags->disable_allocator_tagging).

Testing done manually on an AArch64 VM using both GCC and clang.

This patch makes GenerateRandomTag return a known non-zero tag when tagging
is disabled, which essentially marks whatever pointer is being created as
coming from the internal allocator.

Diff Detail

Event Timeline

mmalcomson created this revision.Oct 16 2019, 9:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 16 2019, 9:30 AM

Remove some superfluous semicolons that were causing warnings.

Another approach I considered was to make GenerateRandomTag return a known
non-zero tag when tagging is disabled for the current thread.

I think this is not a bad idea. Could we use a fixed non-zero tag in the allocator under the same condition, i.e.

(t->TaggingIsDisabled() && !flags()->disable_allocator_tagging)

@pcc WDYT?

compiler-rt/lib/hwasan/hwasan_allocator.cpp
130

Wrong indentation here makes it look like REAL(malloc) is called outside of both if-s.
Please use clang-format, and also add {} braces for the outer if block.

pcc added a comment.Oct 17 2019, 4:24 PM

Another approach I considered was to make GenerateRandomTag return a known
non-zero tag when tagging is disabled for the current thread.

I think this is not a bad idea. Could we use a fixed non-zero tag in the allocator under the same condition, i.e.

(t->TaggingIsDisabled() && !flags()->disable_allocator_tagging)

@pcc WDYT?

SGTM.

mmalcomson edited the summary of this revision. (Show Details)

Now avoid returning a zero tag when tagging is disabled.

I've avoided that by returning a fixed non-zero tag from Thread::GenerateRandomTag.

NOTE: There's the same basic problem of tagging with zero going to the system allocator free when setting HWASAN_OPTIONS tag_in_malloc=false. I intend to fix that in a separate patch.

In fact, we are not going to pursue this malloc fallback feature any more, and I doubt anyone else is interested.
Let's simply remove it: D69199.

mmalcomson abandoned this revision.Oct 25 2019, 8:06 AM

Closing given the allocator fallback feature is not being pursued any more.