This is an archive of the discontinued LLVM Phabricator instance.

[ASAN] Add check for not-in-mapping address for mmap
AbandonedPublic

Authored by yingcong-wu on Aug 23 2023, 10:57 PM.

Details

Summary

Add check for not-in-mapping addr for mmap. This will fix the
failure of SanitizerCommon-asan-x86_64-Linux::Linux/mmap_56bit_test.c
in machine that support 5-level paging. Without this check if user
try to mmap a address outside ASAN mapping, then ASAN will use that
address to calculate and get the invalid shadow memory address, which
then lead to SEGV.

Diff Detail

Event Timeline

yingcong-wu created this revision.Aug 23 2023, 10:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2023, 10:57 PM
Herald added subscribers: Enna1, pengfei. · View Herald Transcript
yingcong-wu requested review of this revision.Aug 23 2023, 10:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2023, 10:57 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
vitalybuka requested changes to this revision.Aug 27 2023, 7:10 PM
vitalybuka added inline comments.
compiler-rt/lib/asan/asan_interceptors.cpp
156

Please check https://reviews.llvm.org/D154659#inline-1495335

Asan is suppose to work with prebuild non-instrumented code, so we are not as aggressive here.
Maybe it's fine if we update the check for protect_shadow_gap=0

compiler-rt/lib/asan/asan_mapping.h
389

we should not allow mapping in AddrIsInShadow

This revision now requires changes to proceed.Aug 27 2023, 7:10 PM

Asan is suppose to work with prebuild non-instrumented code, so we are not as aggressive here.

Yeah, I forgot about that. I guess if prebuild non-instrumented code are using mmap to operate memory regions outside ASAN mapping, as long as they keep those addresses to themselves(not passing those not-in-mapping addresses to instrumented code), then it will be fine.

However, there is no guarantee for that. But that looks like a dilemma to me.

yingcong-wu abandoned this revision.Aug 27 2023, 11:11 PM

Abandon this because we want to keep the ability to work with not-instrumented code.