-memory-safe C++ - Jim Radigan - CppCon 2022

cppcon.org/
---
-memory-safe C++ - Jim Radigan - CppCon 2022
github.com/CppCon/CppCon2022
Memory safety issues are one of the most costly and common of software vulnerabilities. They were listed as 6 out of the 2021 CWE (Common Weakness Enumeration) Top 25, and account for 40% of the total points scored for all categories of the Most Dangerous Software Weaknesses listed. To combat this, we introduce a new compiler and runtime to enable building memory safe C++ and C applications. The binaries built with this new tooling require no modifications to source code and can find common memory safety issues such as buffer overflow, double free, use-after-free, new-delete type mismatch, and much more, at compile-time and runtime.
In this talk, we will present the new tooling and discuss how static analysis is key to early detection of program errors in the developer’s inner loop. Using concise examples, we will illustrate scenarios where static analysis can never completely prove memory safety for unaltered C++ or C. We demonstrate how our new tooling addresses memory safety with formal analysis that falls back to runtime checks when required for all safety guarantees. All runtime checks diagnose, report, and allow the application to continue.
---
Jim Radigan
Architect with over twenty years of experience shipping code gen. technology at Microsoft. Shipped C++ compilers, JIT’s, runtimes, and built large retail operating systems for initial release. Experience leading teams, recruiting, while implementing key technologies on the critical path. Implemented key compiler technology for SSA based global optimizations, vectorization, parallelization, coroutines, hot-patching, secure code gen, Asan, JIT’s and IDE functionality. Started and shipped: platforms on V1 hardware and created lasting cross-team processes to bring up Windows XP through Win 11 (for x86, X64, arm, arm64).
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
KZbin Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #cpp

[@simonfarre4907]

Really should rename "Data Oriented Programming" as it can be confused with "Data oriented design" or its less used synonym "Data oriented programming" (which name matches exactly). Data oriented programming/design is a superior idea over Object oriented programming - yes, the video is about a completely different subject, but naming is important.

[@bunpasi]

I wish compilers would come with more of these features out of the box. I'd imagine that at least some static analyses features are relatively easy to implement. This could already be a big help.

[@tdoc666___]

you can't have improvement without continuos challenges, we need challenges to improve, what you said is not actually the best way to get better and smarter, what's the point to live a life if not to experience and improve your own mindset...

[@JJCUBER]

At 46:24 , does it make the A[-1] write to what would have been there if the metadata wasn’t (in the process of “taking the hit”)?

[@sideparting6845]

SAL was useful in a codebase I worked on years ago but it was so so so poorly documented! Fascinating talk, thanks.

[@paulfloyd9258]

Valgrind dev (d)hat on, very interesting. Continuation sounds good. Is there no way to hook the loader so that asan is active during program load?

[@DrGreenGiant]

Interesting talk of some fantastic technology. Was somewhat put off by the parts that very much come across as a sales pitch though.

[@leyasep5919]

40 years ago, some dudes creates Ada...

[@leyasep5919]

Watching this scares me as hell because I know too much what this means, and it's so ugly !

[@zxuiji]

42:29, a simpler solution is to just store the thread id in the lock, start it off as -1 (or 0 if that's always invalid) and when a lock is obtained set that id and increment a reference count, every lock attempt there after from that would then increase that count and the same number of releases would then be required to clear the the thread id let another thread take the lock, it's the solution I came up with for my custom mutex that utilises a system mutex under the hood for the initial lock, 1st thread to acquire the lock, set the thread id and release the lock takes the custom mutex, the other thread/s upon acquiring the lock will check again if the thread id is still empty and return to waiting on it if not.

[@Ch40zz]

Thats called a reentrant/recursive lock, it already exists :)

[@kuhluhOG]

@@Ch40zz yep, called std::recursive_mutex and std::recursive_timed_mutex in case you need one with time limits

[@zxuiji]

9:22, if you can build it into the IDE then you can add it to all compilers you can submit code for, no excuses, it should be made a compile time error, also should add a option to toggle checking for values that have not been 0'd out by the function exit, if there's no sign they're being passed to something outside of the function's scope then they should be cleared by the time it ends, even if it's not compiled into the final byte code, this type of requirement will at least remind the dev that the variable exists and they should make sure it is safely cleaned up. In my case I make liberal use of goto to ensure safe cleanup, here's an example: int foo(...) { int ret = -1; // Default to an unknown error void *mem = calloc( 1, BUFSIZ ); /* Compiler should assume this succeeds and use a non-0 number to track when it's cleaned up, an instance of mem = NULL; should be found shortly before return */ ... if ( /* catch error */ ) goto free_pointer; ... ret = 0; free_pointer: free(mem); mem = NULL; return ret; }

[@zxuiji]

48:31, you can, change the font size, I don't even use windows anymore and I still remember that

[@dexterman6361]

Funny they run it on GCC to show memory errors, but not on MSVC or any other MS tech (apart from vague IoT) itself. Sadge. Goes to show they are ready to poo poo on other projects but not their own. MS has always been this way Good video though! Really interesting tech!

[@stifflery]

:D I think you mistook that specific moment in a wrong manner. He did tell that those errors came from an old GCC compiler version and newer one didn't have any of those memory errors.

[@ordinarygg]

Wait till Rust comment arrives xDDD

[@sideparting6845]

Yes particularly after his comment at 1:00:40!!!

[@svenvandevelde1]

Seems to me you have not understood the content of what has been explained. Rust won't help.

[@manrico736]

rust is coming....

[@CuriousCauliflowerX]

Dynamic analysis is an improvement but it's not sufficient, for dynamic analysis to work you'd need to be able to run all of the code paths ahead of time, which is rare. The way forward is to actually ship the analysis to prod, and at that point you might as well use a better language.

[@krumbergify]

If you don’t run your code before shipping. How do you know if it even works?

[@LeDabe]

that is why you use fuzzing to try to hit all code paths. Though it is obviously not thorough.

[@azarashikamen4098]

Bullshit... Dynamic analysis is a must. Most applications depends on runtime decisions. Shipping application with tools for dynamic analysis is good, but language doesn't matter here.

[@JorgetePanete]

​@@azarashikamen4098 "Bullshit..." If the code is detected as faulty just don't let it compile, and you need specific features to do that