[llvm-dev] Minimal UBSAN runtime with ASAN?

[Kostya Serebryany via llvm-dev]

+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/show_bug.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>