This is an archive of the discontinued LLVM Phabricator instance.

[dfsan] Add a flag to ignore personality routines.
ClosedPublic

Authored by twoh on Dec 7 2021, 9:37 PM.

Details

Summary

This diff adds "dfsan-ignore-personality-routine" flag, which makes
the dfsan pass to not to generate wrappers for the personality functions if the
function is marked uninstrumented.

This flag is to support dfsan with the cases where the exception handling
routines cannot be instrumented (e.g. use the prebuilt version of c++ standard
library). When the personality function cannot be instrumented it is supposed
to be marked "uninstrumented" from the abi list file. While DFSan generates a
wrapper function for uninstrumented functions, it cannot cannot generate a
valid wrapper for vararg functions, and indirect invocation of vararg function
wrapper terminates the execution of dfsan-instrumented programs. This makes
invocation of personality routine to crash the program, because 1) clang adds a
declaration of personality functions as a vararg function with no fixed
argument, and 2) personality routines are always called indirectly.

To address this issue, the flag introduced in this diff makes dfsan to not to
instrument the personality function. This is not the "correct" solution in the
sense that return value label from the personality function will be undefined.
However, in practice, if the exception handling routines are uninstrumented we
wouldn't expect precise label propagation around them, and it would be more
beneficial to make the rest of the program run without termination.

Diff Detail

Event Timeline

twoh created this revision.Dec 7 2021, 9:37 PM
twoh requested review of this revision.Dec 7 2021, 9:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 7 2021, 9:37 PM

Note, related code: https://github.com/llvm/llvm-project/blob/484a569eea7ba294d84b9a700e6fcc2f97626320/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp#L1785

Can continuing execution after an exception could lead to false positives? I'm unsure how primitives on the stack frames are freed during unwind - will stack shadow memory be zero'd during unwinding?

twoh added a comment.Dec 8 2021, 1:30 PM

@browneee Thanks for the pointer!

Can continuing execution after an exception could lead to false positives? I'm unsure how primitives on the stack frames are freed during unwind - will stack shadow memory be zero'd during unwinding?

I don't think stack shadow memory will be zero'd during unwinding, but I also don't think that it will lead to false positives. I think it's basically same as we only adjust the stack/frame pointers to manage stack, not explicitly zero'ing out the stack. Once we push a new value to stack, the corresponding shadow instruction will overwrite the stack shadow memory as well. Please let me know if I misunderstood something. (I guess HWASAN requires explicit untagging because they want to detect the stack overflow.)

browneee accepted this revision.Dec 8 2021, 2:11 PM
This revision is now accepted and ready to land.Dec 8 2021, 2:11 PM
This revision was automatically updated to reflect the committed changes.