[llvm-dev] Minimal UBSAN runtime with ASAN? (original) (raw)

Kostya Serebryany via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 23 10:36:38 PDT 2018

+Evgeniy Stepanov <eugenis at google.com> +Vitaly Buka <vitalybuka at google.com>

Hi Igor, yes, please send the patches for the clang driver and compiler-rt. It might require some refactoring to get minimal ubsan-rt working with asan.

As for vptr UBSAN: I guess that vptr checking does actually require very non-trivial run-time support and is not included into the minimal one.

On Sun, Oct 21, 2018 at 11:46 AM Igor Sugak via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Hello,

In my organization, we've been using ASAN and most of UBSAN checks in the default developers mode with a big success. I'd like to enable a few remaining UBSAN checks too but noticed that they cause significant (up to 2x in some cases) binary size overhead (mostly .rodata and .data). These checks are: null, function, vptr, object-size. Inspecting .rodata, it looks like there are a lot of strings with file and type names. I tried to use -fsanitize-undefined-strip-path-components=-1 from [1]. It appeared to have no effect when -fsanitize=function and -fsanitize=address are used at the same time (filed bug [2]). Disabling -fsanitize=function and using -fsanitize-undefined-strip-path-components=-1 reduces the size overhead to 1.4x. This is quite already significant. I've considered -fsanitize=trap, it causes very little size overhead but it in some cases is hard to work with. I noticed that [3] added minimal runtime for UBSAN. It works similar to -fsanitize-trap, but prints a bit more informative message, which would suffice. Out of the box, I didn't notice a measurable binary size reduction as mentioned on that change, but if used with -fdata-sections -ffunction-sections_ _-Wl,--gc-sections -Wl,--print-gc-sections, the size bloat of .rodata and .data is almost eliminated. Note, in this case, those flags don't help without -fsanitize-minimal-runtime. Unfortunately, there is a restriction in the driver preventing this minimal UBSAN runtime to be used when ASAN is also enabled. I don't completely understand the reasons for having this restriction. When I removed that restriction, both ASAN and UBSAN still seem functioning in my tests. I'd like to allow using minimal UBSAN runtime with ASAN. Are there reasons against it? I'd volunteer to do the work here. Also, vptr UBSAN check is disallowed when minimal UBSAN runtime is used. Would someone clarify why? -- Igor

1. https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#additional-configuration 2. https://bugs.llvm.org/showbug.cgi?id=39347 3. https://reviews.llvm.org/D36810 D36810 Minimal runtime for UBSan. - LLVM <https://reviews.llvm.org/D36810> reviews.llvm.org Not worried about that. If it allocates or prints too much, we can add in a custom allocator or printing strategy. If it requires too much metadata to be inserted into user programs, we can devise a new, smaller encoding for the metadata. https://reviews.llvm.org/D36810 D36810 Minimal runtime for UBSan. - LLVM <https://reviews.llvm.org/D36810> reviews.llvm.org Not worried about that. If it allocates or prints too much, we can add in a custom allocator or printing strategy. If it requires too much metadata to be inserted into user programs, we can devise a new, smaller encoding for the metadata.

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181023/76a69573/attachment.html>

More information about the llvm-dev mailing list