This is an archive of the discontinued LLVM Phabricator instance.

[asan] Support running without /proc
ClosedPublic

Authored by eugenis on Dec 28 2018, 3:14 PM.

Details

Summary

This patch lets ASan run when /proc is not accessible (ex. not mounted
yet). It includes a special test-only flag that emulates this condition
in an unpriviledged process.

This only matters on Linux, where /proc is necessary to enumerate
virtual memory mappings.

Event Timeline

eugenis created this revision.Dec 28 2018, 3:14 PM

This is a second attempt at this.
This time, instead of checking for /proc/self/maps accessibility in advance, we tolerate a failure to read that file, and make it look like an empty mapping list. There is an optional Error() method of MemoryMappingLayout that can be used to detect this condition.

vitalybuka added inline comments.Dec 28 2018, 4:03 PM
compiler-rt/lib/sanitizer_common/sanitizer_posix.cc
342

what if instead of this we add
common_flags()->procfs_path and set it to /proc/ by defaut?

There is a related issue on NetBSD. Right now proc map cannot exceed 10MBs (it was raised from 1MBs) (when using sysctl(3) interface, there is a complicated way to workaround it and read kernel structs directly).

Part of the tests (libFuzzer ones) were fixed with this kernel change, but there is still issue with at least: test/tsan/ignore_lib5.cc.

Can we handle with this change a similar scenario that proc map is too large to be retrieved? If so can we generalize no-/proc to no-memorymap?

eugenis marked an inline comment as done.Jan 7 2019, 12:38 PM

Can we handle with this change a similar scenario that proc map is too large to be retrieved? If so can we generalize no-/proc to no-memorymap?

Does this look like an error return from internal_sysctl in ReadProcMaps? Sure, we can mock that condition with the same flag.

compiler-rt/lib/sanitizer_common/sanitizer_posix.cc
342

Not sure about that. It would take a mock flag, and disguise it as a user flag. Unless there are actual practical cases where procfs is mounted somewhere other than /proc, all this would do is confuse people, IMHO.

Can we handle with this change a similar scenario that proc map is too large to be retrieved? If so can we generalize no-/proc to no-memorymap?

Does this look like an error return from internal_sysctl in ReadProcMaps? Sure, we can mock that condition with the same flag.

Yes, we receive E2BIG. The current behavior is that on some assert() the code hangs.

eugenis updated this revision to Diff 180565.Jan 7 2019, 2:37 PM

renamed the flag

Sure. I've renamed the flag, but I'd like to leave the actual *bsd implementation of it and the Error() handling to you as I don't have the setup to test it.

vitalybuka accepted this revision.Jan 7 2019, 4:25 PM

LGTM

compiler-rt/lib/sanitizer_common/sanitizer_posix.cc
342

add tests into name e.g. test_only_procfs_path
this will be more generic, maybe let some one add useful tests with about the same complexity of the flag implementation

compiler-rt/lib/sanitizer_common/sanitizer_procmaps_bsd.cc
102

why it's CHECK here and "return false;" on linux

This revision is now accepted and ready to land.Jan 7 2019, 4:25 PM
eugenis marked 2 inline comments as done.Jan 7 2019, 4:49 PM
eugenis added inline comments.
compiler-rt/lib/sanitizer_common/sanitizer_posix.cc
342

this would conflict with @krytarowski request for emulating E2BIG on *bsd

compiler-rt/lib/sanitizer_common/sanitizer_procmaps_bsd.cc
102

That's because ReadProcMaps for *bsd never sets data to nullptr, it aborts instead.

This revision was automatically updated to reflect the committed changes.