Noob question from friend of cybersecu guy

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

clang -fsanitize=undefined might be what you're looking for.

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

Cheers,
Victor.

Hello,
Oh thank You. Thats what i was looking for. I hope it includes unspecifieds too.

Best regards,
Pawel Kunio

śr., 21.04.2021, 10:21 użytkownik Victor Campos <victor@victorcampos.me> napisał:

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@victorcampos.me> napisał:

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

Aah. Thats enlightening thank you for extremely detailed explanation. I understand better how to design my ideal complang now.

Imho rust is not 100% perfect security-wise but still much better than c and c++ and still keeps those templates lambdas etc.

Looking forward to rusts linux use. My friend is using it above embedded os from apache on riscv platform for lora board from pine.

Id think something cycloneish or checkedcish at leash for transition time is closer hit. Im also from this old sad school of pascal delphi etc.

Best regards,
Pawel Kunio

śr., 21.04.2021, 14:27 użytkownik David Chisnall via llvm-dev <llvm-dev@lists.llvm.org> napisał: