-memory-safe C++ - Jim Radigan

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

Рет қаралды 22,091

Жыл бұрын

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
KZfaq Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #cpp

Пікірлер: 25

@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.

@sideparting6845 Жыл бұрын

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

@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___ 6 ай бұрын

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”)?

@DrGreenGiant Жыл бұрын

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

@paulfloyd9258 10 ай бұрын

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?

@leyasep5919 Жыл бұрын

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

@leyasep5919 Жыл бұрын

40 years ago, some dudes creates Ada...

@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; }

@ordinarygg Жыл бұрын

Wait till Rust comment arrives xDDD

@sideparting6845 Жыл бұрын

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

@svenvandevelde1 11 ай бұрын

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

@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!

@deleater 3 ай бұрын

: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.

@manrico736 4 ай бұрын

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