Keynote: Safety and Security: The Future of C++ - JF Bastien - CppNow 2023

www.cppnow.org​
/ cppnow
---
Keynote: Safety & Security: The Future of C++ - JF Bastien - CppNow 2023
Slides: github.com/boostcon
---
www.cppnow.org​
/ cppnow
---
Safety and security are currently being called “an existential threat to C++”. To me C++ is a tool, a useful one, but at the end of the day it’s a tool. It has flaws which could be remedied, and there are other tools out there.
This talk will discuss how we got to an existential threat, and what our responsibility is now that we’re here. I’ll make the case that C++ is critical infrastructure, and that we have an ethical responsibility to remedy its problems. Doing so requires maturing the field of software engineering, which starts by understanding what “safety and security” really are. I’ll advocate for a scientific approach to resolving the problem, and conclude with a discussion of whether C++ is worth saving.
---
JF Bastien
JF is chief architect at Woven by Toyota. He chairs the evolution of the C++ programming language. JF has worked on a variety of compilers for a variety of programming languages, implementing language features, improving performance / security / safety, targeting novel architectures, and other fun things. See jfbastien.com.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
KZbin Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org​
/ cppnow
---
#boost #cpp #softwareengineering

[@tylovset]

Great talk. The safety != correctness is an incredible important point which many don't understand. Safety will reduce mistakes and I'm all for it, but the danger is that people will overlook subtle bugs in code that isn't implemented according to specs, or code that implements faulty specs. There seems to be a dangerous trend/belief that safe code must be correct if it compiles. That won't happen before computers can prove that a piece of code is implemented correctly according to specs, *and* that the specs can be proven to achieve the overall goals of the program.

[@aperson4051]

Great talk!

[@Roibarkan]

Really great and thought provoking talk. I’m trying to think what might be ‘a seatbelt’ in C++, and note that all cars I know (JF mentions that some are stricter) allow their operators to drive without a seatbelt (although people typically use seatbelts, and laws require it). Thus, I might consider the ‘C++ Core Guidelines’ as ‘a seatbelt’ - the compiler might detect and warn about them, but not mandate them. I’m happy to hear what other people see as ‘seatbelts’ for the language (and specifically question whether a rust-like borrow checker is akin to a seatbelt, or perhaps it’s more like airbags). I’m not sure if it’s truly practical to debate a seatbelt-vs-airbag notion, though.

[@KohuGaly]

The warn vs. mandate IMO should simply be configurable. The flipside is that making something mandatory let's you make stricter assumptions. The flipside of stricter assumptions is that they impose stricter requirements. Rust's borrow checker is a good example of this. Technically, it's just a lint - theoretically it's not a necessary step in Rust's compilation. But since it's mandatory, it's possible to have perfect automatic aliasing annotations on pointers. The converse of that is, nearly every borrow checking violation is instant undefined behavior. Working directly with pointers in Rust is notoriously UB-prone. The borrow checker being mandatory enabled entirely new performance-safety tradeoff.

[@fdwr]

22:29 "who's responded to a zero day exploit" - 🖐 Someone could send a specially crafted Arabic string (not linguistically valid text) with certain bidi characters to crash the Windows phone messaging app due to uninitialized variables when going through a certain code path. So, try persuading me that uninitialized should be the *default* language state (rather than an explicit opt in for performance with some keyword or attribute), and you will fail to persuade me.

[@WilhelmDrake]

@39:41 Buildings are safe because of government regulation. Government Regulation makes modern life possible.

[@10100rsn]

15:10 Static Reflection can help give you everything else above "Reflection" on that list. It will change the way you program.

[@Roibarkan]

29:38 Thomas Dullien’s talk: kzbin.info/www/bejne/Z6rRnIqZm86qhc0

[@Roibarkan]

1:24:52 JF’s talk from 2018: kzbin.info/www/bejne/gJm4qXyMm5akpc0

[@kuhluhOG]

I would argue that "no deadlocks" is also part of thread safety, not just "no data races".

[@adamsnaider5535]

Deadlocks don't lead to undefined behavior which is the main point he's covering with thread safety. You can't exploit a deadlock

[@kuhluhOG]

@@adamsnaider5535 depends on how you define "can't exploit" if your goal is a DoS, a deadlock can very well be used as an exploit

[@Roibarkan]

56:22 llvm talk on bounds safety: kzbin.info/www/bejne/iHyck5moqLKXd68

[@4otko999]

by the way, why don't you use ada for automotive? i believe it has the iso certification thingy

[@oleksandrkaleniuk7813]

We need specific regulations not ethics. All that home-made codes do is harm the reputation of proper legislation. Imagine that instead of traffic code, we'd have some Ford driver's code of conduct, bicyclists code of ethics and... nothing else.

[@JohnWilliams-gy5yc]

I don't think it would be long when we discover zero-day in explicit "unsafe" segment of codes. I mean that it's just illogical to say there is a difference among two people who both use seatbelts and there is a difference among who don't use them. Teaching people why they need seatbelts is only way to save them.

[@zxuiji]

1:13:36, that root id issue is rather easily solved, the kernel just has to assign a random negative value during boot to root id so that the root uid is never the same on each boot and can be anything between INT_MIN and -1, 0 will always mean invalid uid then

[@dariuszantoniuk]

How long a prelude does a C++ audience need before acknowledging possibility of safety issues? About 50 minutes

[@robertbruce7686]

😂😂😂😂

[@zxuiji]

I think another way to produce memory safety in C/C++ is to just use JIT handlers, similar to how emulators use JIT to make the original binaries believe they're on the actual hardware we could use the same thing to force memory safety in C/C++ binaries on the server side as for the client side we only really need to run them through the JIT during the test phase prior to release. I'll edit in some links if I happen to find any in the search I'm about to do having only just thought of using JITs **Edit:** Had another idea while I was searching, just designate a specific function for global offsets that can then grab the offset from a global buffer, something like: ((object*)at(ptr))->member = x; or AT(object,ptr)->member = x; If the offset is not supposed to exist then it just returns NULL for a segfault, yes it's a bit more annoying then a simple object->member = x; but it does the job reasonably fast for debug purposes and can even be used as a macro like this: #if defined( _DEBUG ) || defined(_SERVER) #define AT(T,PTR) ((T*)(at(PTR)) #else #define AT(T,PTR) ((T*)(PTR)) #endif

[@gottfriedtheimer8497]

C++ with JIT exists. See Java, C#

[@masheroz]

How can there be no audience microphone at a keynote?

[@joeedh]

Choice theory applies to consumers, not engineers. Engineers are system optimizers. The set of possible choices that meets our optimization criteria is always much smaller than the total set of ways of doing things. The choice often comes down to 2 or 3 methods.

[@joeedh]

If you feel overwhelmed by the number of ways of doing a problem then you don't understand that problem.

[@richardvonlehe4581]

On slide 56 I couldn't help but think of Toyota's unintended acceleration.

[@Heater-v1.0.0]

I'm not sure why those safety and security "experts" of the NSA or NIST or wherever would want to join in the C++ standards committee or other C++ efforts. I'm mean, would you expect them to contribute to security of assembly language? No, they know it is a lost cause. They know, or think they know, of better ways to achieve what they would like to see.

[@gtdcoder]

I think there needs to be a distinction made between safety and compiler-guaranteed safety. It's quite possible to write programs that are perfectly safe and secure but would not be allowed by compilers like the Rust compiler. The set of all possible safe programs is much larger than the set of safe programs that can be guaranteed by compilers or other tools. Since it is not possible for compilers to guarantee safety for all programs then why is that guarantee now considered a moral imperative for every language? If it was possible then of course it should be required. But it is not possible. Just look at the Rust community. It is common for them to make use of the "unsafe" keyword or to disable the borrow-checker. Otherwise some of the programs they want to write would not be correct. There's always a tradeoff between guaranteed safety and correctness but not between safety and correctness. It should always be possible, in C++ anyway, to achieve both safety and correctness, but the safety will not be guaranteed by the compiler in all cases. It's up to the programmer in the other cases. That's also true of Rust except there is this myth that you can achieve guaranteed safety in all cases. You could argue that it is easier in Rust because it has better defaults but that usually doesn't outweigh the cost of migrating to a whole new language. I think modern languages are guilty of the same fallacy that created the Bitcoin and AI crazes. This idea that software is smart enough to save us from ourselves. That is simply not true. Compilers actually are not that smart. At least not until a super AGI is invented and that is not going to happen anytime soon. But if it did, there would be no more computer languages because the machines would write all the code.

[@digama0]

"It is common for them to make use of the "unsafe" keyword or to disable the borrow-checker." It is not possible to disable the borrow checker in Rust. There is no chance of getting an RFC for that through as it is anathema to the safety culture. As for using the unsafe keyword, it is empirically observable that it is not common - it is used somewhere in the 1-2% range.

[@SimonToth83]

I don't like the seatbelt analogy here. C++ does have seatbelts, and going back to another point, there are plenty of software areas that are in fact heavily regulated. The problem is that to understand how to use the "seatbelt feature" you need to read the fine print in a 1000 page manual. Or alternatively pay a lot of money to a company that will provide a seatbelt (Static Analyzer) for you. Shocker, that doesn't scale as well as the original Volvo approach, but the problem isn't the lack of seatbelt technology.

[@fdwr]

1:40:10 "Is C++ worth saving?" Definitely, as there are many existing codebases that need to integrate cleanly with new code, and the naive "rewrite it in ____" mindset ignores the toolchain issues and the matter of other new bugs being introduced from the porting process. Also, using current C++ is like driving without a seatbelt. Using Rust is like driving in a straitjacket with leg irons 😅. Neither of those is particularly great, leaving room for a healthy hybrid where defaults tilt toward correctness (avoiding switch case fallthrough by default, uninitialized variables by default...).

[@The1RandomFool]

I may not like Obama, but that is objectively good advice in that quote. It's also what I do.

[@zxuiji]

21:08, to them I would say the same I say to C++ devs who refuse to use, C is simpler to understand, it's easy to see where you've gone wrong once you know where you f***ed up, other languages (C++ included) obfuscate all that, they're fine for isolated development cases but as 99% falls back to C under the hood it's far better to learn to program in C at minimum and treat any other language as a means of reducing the amount of care you need to put into what you're doing. Take HTML for example, that's designed explicitly for f***-ups but is a major nuisance to those who need more control over they're making. In other words, use the "guards" when you don't need the extra control but when you do need the extra control drop the "guards" since they'll only get in the way. Personally I favour going without guards since I only need to put in extra effort to test for dumb ass mistakes, for those who move to it from C++ and miss having templates & inheritance, use #define, #include & #undef to mimic them. For those who love linked lists but not the slow access when going for specific items, you can keep the benefits of both at the cost of double the memory, one buffer for the actual data (which keeps the continuous feature generally preferred for it) and another buffer for the links, the links should be offsets within the list (head being +N from root) where the next/prev link can be identified by adding the offset to the pointer of the current link, so for example: link = list->root + list->head or link = list->root + i; Could both result in getting the head pointer (or any link within the buffer) and the below is what you would use if it's a looped list to go through it without checking for NULL do { ... link += link->next; } while ( link != head );

[@Fareoneo]

Rust: the future of c++

[@CuriousCauliflowerX]

43:15 - rust has indeed fixed in-process data races, so your joke about how data races are unfixable is not actually accurate.

[@zxuiji]

Not really, it just moved the problem to "unsafe" code where the compiler doesn't get to control what you can and can't do as much

[@CuriousCauliflowerX]

@@zxuiji I've been working in rust for more than 3 years and have never needed to use unsafe, so no. Give it a shot, you might like it.

[@deepfakescoverychannel6710]

Life is too short to program in C++. Instead of achieving the idea, you get into an eternal battle with templates and implicit behavior, and in the end the code will still be ugly and not satisfying, only an eternal pain. After 15 years of programming in it, I realized it very late, and spent so many years on this unpromising language. A person who talks intelligently about safety and correctness in C++ looks like a preacher in a ruined city. By now C++ should look like Google Carbon or Rust. You destroyed C++. C++ is dead.

[@zxuiji]

Have you tried C? You can mimic both inheritance and templates with #include btw, I'd argue it actually makes code more readable and throws out the annoyances of c++ versions of the same, you just lose out on the implicit "this" pointer meaning you have to be explicit, minor greavance. If you do end up using the #include thing then just note, you'll need manually defined inline wrappers for the intellisense to capture, that aside it is much easier to program in than c++.

[@oleksandrkaleniuk7813]

Also the "software is a new thing" argument is getting old. Software is older than nuclear power plants, computer tomography, and jet propulsion in aviation. All being incredibly "mature" and maybe even overly-regulated at this point.

[@kuhluhOG]

these things individually may be young, but they are only part of a bigger industry jet propulsion for example is to mechanical engineering what browsers are to software engineering

[@joeedh]

Ah yes, the fallacy of choice theory. A common mistake of consultant types.

[@aratosm]

Such a bad video. 2.8% like to view ratio because most examples make 0 sense.

[@4otko999]

I think you need to do unsafe stuff to stay competitive. Look at the firefox, their marketshare dropped below 3% not because their browser is unsafe, but because it's a poorly implemented browser. Software is need to do unsafe stuff because it's faster and more optimal in general, but it should work predictably. I like seatbelt analogy, cars are unsafe, people die in crashes, yet they still use cars, but with some safety measures. You might as well ride a bicycle, but to travel further you need to go faster and that is essentially unsafe. If there is a demand for memory safety, i think c++ should not ignore that demand. So folks like mozilla could fix their bugs instead of inventing entirely new language and going out of business because now they still do bugs, but can't really fix them because compiler disagrees. And on top of that, firefox is still the slowest browser. I think c++ should empower people to do what they want to do, if they want to write memory safe code, perhaps c++ should somehow help those people. This is why we like c++: it let us do what we want to do. I am personally wouldn't want to work with something like rust because it's inconvenient language and i see what it did to mozilla and i dont want it to do the same to, let's say, linux. From my point of view, things are falling appart when people use rust. I understand the utility, but imo it's not the way forward. Like sfinae was not a way forward. And i find it very strange if language is marketing itself on a basis that it doesn't let you to do stuff. Hopefully c++ will be able to address this.

[@zxuiji]

Much prefer C myself, a lot easier to understand at a glance than C++ with all it's convoluted additions. That aside still gave you the like for essentially pointing out that memory safety should not be controlled by the compiler. Also still prefer firefox since it's the only one to support the addons I want and the only one to allow lack of telementary. Note that I said allow rather mandate like I presume brave does (not that it would change my choice of browser due addon support). As for "poorly coded", what do you expect? It supports way more than chrome etc, it has better addon support, presumably around half it's users turn off telementary like I do, it's good enough for it's targets and still the best browser around