Safety and Security for C++: Panel Discussion - Hosted by Michael Wong - CppCon 2023

cppcon.org/
---
Safety and Security for C++ - Bjarne Stroustrup, Gabriel Dos Reis, Andreas Weis, Michael Wong, Nevin Liber and Verena Beckham - CppCon 2023
Safety and Security has become a key discussion topic in recent years in C++, especially culminating in the last 2 C++ Standard meetings in Issaquah, and recently in Varna. In fact, The C++ Direction Group has been discussing it for several years, and there has been an effort to liaison with external groups such as WG23, MISRA, and other ISO. There has been several keynotes + presentations on Safe and/or Secure C++ as well as multiple talks at previous CPPCON on MISRA, and C++ Core Guideline (including parallel programming guidelines) directions. Now there is also a Study Group 23, which specifically looks at proposal in this domain.
This panel, the first at CPPCON 2023, should be the beginning of a continuing series of panel at every future CPPCON where we will have the opportunity to discuss the progress of Safe and Secure C++, to enable the improved use of C++ in the Automotive, Embedded, Space, Medical or any domain that requires safety and security.
The panel will present recent works in safe and secure C++ in the committee, as well as outside ISO committees such as 26262/21488 as well as recent coverage on AI/ML safety (8800). It will allow us to cover progress in MISRA, C++ Core Guidelines, as well as vulnerabilities discussion in CVE. This will be followed by a guided discussion with the audience to enable further input to allow C++ safety and Security to evolve with the help of the audience and outside experts.
---
Michael Wong
Michael Wong is Distinguished Engineer/VP of R&D at Codeplay Software. He is a current Director and VP of ISOCPP , and a senior member of the C++ Standards Committee with more then 15 years of experience. He chairs the WG21 SG5 Transactional Memory and SG14 Games Development/Low Latency/Financials C++ groups and is the co-author of a number C++/OpenMP/Transactional memory features including generalized attributes, user-defined literals, inheriting constructors, weakly ordered memory models, and explicit conversion operators.
---
Bjarne Stroustrup
Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (4th Edition) and A Tour of C++ (3rd edition), Programming: Principles and Practice using C++ (2nd Edition), and many popular and academic publications. To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 30 years.
---
Andreas Weis
Andreas Weis has been writing C++ code in many different domains, from real-time graphics, to distributed applications, to embedded systems. As a library writer by nature, he enjoys writing portable code and exposing complex functionalities through simple, richly-typed interfaces. Both of which C++ allows him to do extensively. Andreas is also one of the co-organizers of the Munich C++ User Group, which allows him to share this passion with others on a regular basis.
He currently works for Woven by Toyota, where he focuses on building modern software for use in safety critical systems.
---
Gabriel Dos Reis
Gabriel Dos Reis is a Principal Software Engineer at Microsoft, where he works in the area of large scale software construction, tools, and techniques. He is also a researcher, and a longtime member of the C++ community, author and co-author of numerous extensions to support large scale programming, compile-time and generic programming.
---
Nevin Liber
Nevin “🙂” Liber is a Computer Scientist in the ALCF (Argonne Leadership Computing Facility) division of Argonne National Laboratory, where he works on Kokkos and Aurora. He also represents Argonne on the SYCL and C++ Committees, the latter as Admin Chair, Vice Chair of LEWGI/SG18 and Vice Chair of the US Delegation.
He has worked in C++ across various industries and platforms (big data, low-latency, operating systems, embedded, telephony and now exascale computing, just to name a few). He has also been a C++ Committee member since 2010 and hosted both the C++ and C standards meetings in Chicago.
---
Verena Beckham
Verena Beckham is the VP of Safety Engineering at Codeplay Software. She helped initiate and is now the chair of the SYCL SC Working Group within Khronos, which is defining a version of SYCL that can be more easily safety-certified. Before becoming VP she was a compiler engineer, working mostly on the LLVM backend.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp

[@franciscogerardohernandezr4788]

Extending discussions into the happy hour should be mandatory in all C++ conferences.

[@beachedwhale]

This feels like a lot of repetitive whataboutism and gas lighting of what people want to address, making C++ more safe in the areas of memory safety. So things like dangling ref/ptr's and out of bounds. There seems to be resistance to talking about how they see these issues being mitigated. It took a fight to get the dangling issue in for loops addressed and seems like perfect is killing good here.

[@foobar69]

talk about safety and security and then put all those guidelines like autosar and misra behind paywalls

[@bearwolffish]

Glad Bjarne, still here to speak for himself and to defend cpp.
Great talk to keep having.

[@azdinator]

Is there any follow up of that discussion ?

[@user-tz1ui7mb4i]

Just looking at CppCon 24, and there is no security track...

[@yaroslavpanych2067]

Bjarne casually flexing.
Tbh, It would be enough to just say his name.

[@wolfgangrohringer820]

Feds: "Buffins discovered that seatbelts and airbags significantly lower the number of casualties in car accidents. Let's ensure they're included in future models."
Cpp: "There's no such thing as completely safe driving on public roads. What we need is training and incentives for responsible driving. Safety features alone won't save every driver, nor prevent all accidents."
Feds: "But surely, installing basic safety equipment can't hurt, no?"
Cpp: ""Well... we do offer optional seatbelts. On newer models, you can even add bumpers yourself, should you see the need. If you drive an ambulance, for instance, or something similar. But we believe in a tailored approach. Let individuals choose the safety features they find suitable for themselves. Some find seatbelts restrictive and might opt for, say, a louder horn to enhance safety. We could compile a guideline to suggest some of these measures as best practices. Maybe distribute them in public libraries.
Feds: "But the numbers look quite good for seatbelts and airbags, specifically. Plus, in our experience we are ignored if we just recommend something instead of making it mandatory by law.
Cpp: "...m..mandatory? No, that's not ideal. Mandating airbags would mean people have to fit new steering wheels, which won't accommodate older models. But people expect that they can install the latest steering wheels, always. Also, retrofitting all the older vehicles is not feasible, given their numbers. Plus, the added weight could slightly reduce speed."
Feds: "... you might have a point. We've heard complaints about fuel consumption and minor slowdowns in brands that introduced windshields previously, though overall they've become quite popular..."
Cpp: "Those aren't suited for low-level driving, you know."
Feds: ""Right. But we've come across a new brand that keeps up in acceleration and speed, and includes airbags and seatbelts. It also boasts easier installation of optional parts. Much simpler than your CBrake system, apparently."
Cpp: "Ah, of course! 'Airbags,' 'seatbelts'-it figures you'd get these ideas from those evangelists and their underhanded marketing tactics, constantly attacking us! Their cars lack maturity compared to our tried-and-tested fleet. And we've heard they're quite susceptible to Rust..."

[@yurkoflisk]

Tbf seatbelts is more analogous not to language-level security features designed to prevent certain types of bugs altogether (as Rust intends to; it'd be "preventing cars from crashing"), but to system-level security features which prevent the bugs from being critical (i.e. car crash is less likely to be deadly). So their discussion actually was largely about seatbelts.

[@wolfgangrohringer820]

​@@yurkoflisk That's fair and makes sense. By the way, the discussion on "seatbelts" in this sense is interesting, and the perspective of the functional safety experts is certainly important to hear.
I am just a bit frustrated with this discussion in this specific context. For sure, memory safety doesn't help against kneecapping an operator to get a password. But how is this helpful here? If you can improve things at a language level, of course you will have fewer defects in programs, which is desirable regardless of system-level measures in place. Also, the "it's not just memory safety" argument cuts both ways, since languages like Rust are also about things like good defaults, a modern module system - that you can use today - preventing a class of C++ issues with ADL / ODR violations , proper destructive move semantics (as default, compared to copy), etc.
The second argument that frustrates me is: "Just follow guidelines and use the proper set of tooling, and things are fine". Also this is true, technically. But the best support for preferring a strict compiler to guidelines, optional static analysis, linters and libraries is the very complaint from the discussion about people still not embracing RAII and generally writing a lot of "C/C++". If it can be done, it will be done.
For the record, I have grown to love C++ even though I started to use it professionally around the same time I also started to learn Rust. I also have nothing but respect for the panelists.
I am certainly glad to hear about developments such as the hardened compiler mode and safety profiles. At least for safety profiles, though, it is a bit disheartening to consider that C++29 is something of a best-case scenario for them to arrive.

[@blahbl4hblahtoo]

To be fair, memory safety is the thing that has been a multi billion dollar security problem. Generalizing the conversation to "what does safety even mean" keeps us from making progress.

[@weichslgartner]

This. Was very functional safety focused and talking more about correctness in general while ignoring the fact that memory-safety issue contribute to 70% of the security issues and that this issue is C and C++ specific. The functional safety people normally do a hazard and risk analysis once, follow their ISO standard, use certified toolchains etc. They don't defend against a malicious attacker.

[@krumbergify]

10:31 Don’t talk about Voldemore.
Let’s instead state that we don’t need Rust because security bugs can still occur. What a way to avoid the subject 😂.

[@MrlegendOr]

3:38 Lex Luthor?

[@sanjaygatne1424]

language as part of system we want c++ simple and safe language but "backward compatibility" and discussion goes on for ever, so c++is not simple and safe language.

[@markomacek920]

The problem is also: is there a safe and performant subset (or derivative) of c++ that isn't basically Rust in it's core.

[@kuhluhOG]

@@markomacek920 If that is supposed to be a question: I would say yes.

[@Heater-v1.0.0]

"Why security is in focus now?" Did nobody notice there is a major war going on in Europe for two years now?