llvm dev - Apr 2021 - Noob question from friend of cybersecu guy

Hello,
Oh i found out its mostly or only runtime. I was thinking of something
similar but mostly or only compile-time. Its great base for my solution
though.

Best regards,
Pawel Kunio

śr., 21.04.2021, 10:21 użytkownik Victor Campos <victor at
victorcampos.me>
napisał:
> clang -fsanitize=undefined might be what you're looking for.
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
>
> Cheers,
> Victor.
>
> On Wed, 21 Apr 2021, at 03:55, pawel k. via llvm-dev wrote:
> > Hello,
> > In previous life i knew one cybersecu bounty hunter. As a leftover
from
> > then, i was wondering whether it would be useful and feasible to have
> > in clang or clang static analyzer the checks for two classes of
awkward
> > types of code. Namely c++'ses 191 undefined behaviours and 52
> > unspecified behaviours. That could possibly help to automatically
> > pinpoint the nonportable or randomly code working only because of
> > coincidence. Whether wed warn or err on such shall be up for
discussion.
> >
> > Sorry if that is super obvious and already implemented or np hard or
> useless.
> >
> > If interested author of csmith might know something about full list of
> > these as he is author of randome code generator that avoids genning
> > code with such artifacts.
> >
> > Best regards,
> > Pawel Kunio
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev%40lists.llvm.org>
> > https://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/20210421/03031ffc/attachment.html>

In general, 'undefined behaviour' exists in C/C++ for things that are 
considered infeasible to check statically and too expensive to check 
dynamically.  For example, accessing past the end of an array is UB 
because statically checking would require carrying the bounds 
information through every pointer cast across compilation units and 
tracking the range of the integers used in any array indexing or pointer 
arithmetic.  Use after free is UB because tracking whether any alias of 
a given pointer has been passed to free at any point before the pointer 
is used.

The static analyser does a lot of best-effort checks for these, but 
finding them all in the general case is infeasible.  A few of them are 
trivial (in C, it is UB for your source file to not end with a newline, 
because YACC couldn't express EOF and so early C compilers would 
generate parse errors in this case.  Clang and gcc can warn you about 
this without needing to involve the static analyser).  Any work that 
improves the number of cases that the analyser warns (without generating 
many false positives) is useful, but many of these remain intractable 
for static analysis in the general case.  Safer languages such as Rust 
or C++ with the Core Guidelines don't solve the general case of these 
problems, they just prevent people from writing (valid or invalid) 
programs that are not amenable to static analysis.

David

On 21/04/2021 13:19, pawel k. via llvm-dev wrote:
> Hello,
> Oh i found out its mostly or only runtime. I was thinking of something 
> similar but mostly or only compile-time. Its great base for my solution 
> though.
> 
> Best regards,
> Pawel Kunio
> 
> śr., 21.04.2021, 10:21 użytkownik Victor Campos <victor at
victorcampos.me
> <mailto:victor at victorcampos.me>> napisał:
> 
>     clang -fsanitize=undefined might be what you're looking for.
> 
>     https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
>     <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>
> 
>     Cheers,
>     Victor.
> 
>     On Wed, 21 Apr 2021, at 03:55, pawel k. via llvm-dev wrote:
>      > Hello,
>      > In previous life i knew one cybersecu bounty hunter. As a
>     leftover from
>      > then, i was wondering whether it would be useful and feasible to
>     have
>      > in clang or clang static analyzer the checks for two classes of
>     awkward
>      > types of code. Namely c++'ses 191 undefined behaviours and 52
>      > unspecified behaviours. That could possibly help to automatically
>      > pinpoint the nonportable or randomly code working only because of
>      > coincidence. Whether wed warn or err on such shall be up for
>     discussion.
>      >
>      > Sorry if that is super obvious and already implemented or np hard
>     or useless.
>      >
>      > If interested author of csmith might know something about full
>     list of
>      > these as he is author of randome code generator that avoids
genning
>      > code with such artifacts.
>      >
>      > Best regards,
>      > Pawel Kunio
>      >
>      >
>      > _______________________________________________
>      > LLVM Developers mailing list
>      > llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>     <mailto:llvm-dev%40lists.llvm.org
<mailto:llvm-dev%2540lists.llvm.org>>
>      > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>      >
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>