Memory Safety: Rust vs. C - Robert Seacord - NDC TechTown 2024

[@jeffmcclintock]

"We've been working on safety for 50 years and RUST is still in diapers" The developers of RUST WERE C/C++ developers and they took all that knowledge (that you imply is exclusive to C/C++ developers), learned from C's mistakes, and built a better language. RUST didn't start from scratch on safety, it started from where C/C++ are at and then went further.

[@qwertyman1511]

15:33 does rust have anything in the charter? Response: "[rust should be ] secure by design" > gets ignored

[@qwertyman1511]

29:49 they got put on trial for illegal vendor lock-in in the trains right? Software that geofences who can do maintenance. That is not a math error.

[@fnizzelwhoop]

This talk is less about memory safety and more about hurdles with regards to Rust adoption in specific high-assurance industries.

[@mrpocock]

I did get the impression that the most important genuine issue is the certification ecosystem.

[@krumbergify]

@@mrpocock Yes, the advantage of C and C++ seems to be that the automotive industry is too slow to allow certification of anything actually safer.

[@mrpocock]

@krumbergify it is understandable. That's a hard, time consuming and expensive job. Sometimes it is easier to use a bad tool you know well than a good tool you do not.

[@krumbergify]

50:50 Good type systems do eliminate a lot of input validation issues. Ada allows you to define numeric types with custom ranges that can be checked in compile time.

[@toby9999]

All of that stuff adds overhead.

[@stzi7691]

@@toby9999 Yes, segfaults, off - by one and conversion issues add alot of overhead. My astude answer: And? For the Application Layer and controlled exact calculation part Ada is a blessing. And Ada also has a very good C-API, so I have two very good tools... and not much more is needed. I still have my C Hot-Rot for special bus / peripheral situations. It may add overhead, but well crafted overhead for good programmers. And I, on the otherhand, reduce overhead at my nervous system of debugging code while having angry customers shouting at me.

[@z853c7]

nice that they have invited programmers_are_human_too to this event

[@qwertyman1511]

27:22 arm and x86 has to be 90% marketshare. Sure, if you have to you have to, but then the discussion becomes do we invest in creating our own certified rust toolchain for the hardware we want VS do we change our hardware VS use C. These pricetags might be comparable.

[@MrPetzold123]

"We have been working on these problems for 50 years, we have accomplished a lot and Rust is here in diapers..." ...oh please. Just *what* have you accomplished in 50 years ? There aren't even basic spatial memory safety features like bounds checking as easily usable / default. Look, I like C, I really do, I write C everyday, but this has to be one of the most arrogant and least humble talks I've ever seen 🤯...edit. Anyway, it's nice that even C and C++ folks are starting to *really* take these things seriously now that finally a credible threat (Rust) has arrived (Turbo Pascal had modules in the 80's, Free Pascal has had bounds checking / overflow checking for a looonnggg time etc etc) 😂...edit. spatial.

[@AapoAlas]

One item left out from the memory safety list is (arguably) data races.

[@iuiui-iuiui]

That's usually under thread safety umbrella

[@mrpocock]

I think the point the speaker is missing is that c has been around since before I was a kid, but no amount of tooling or programmer skill has reduced the critical bug rate. The only way to get secure C is for the code to be old enough that the security issues have manifested. He keeps pointing to solutions that either are shown to not be effective by or decades of experience, or which rely upon things that may happen some time in the future. I am not saying Rust is the solution to all and everything. But at least it genuinely does areas memory safety, and through lifetimes, let's you express complex correctness contracts in ways the compiler will check. And yes, Rust likely would have prevented croudstrike, because if the system was written in Rust, the type system would have caught it ideally at compile time but definitely at test. You can't just cast things in Rust. You couldn't have had something expecting 21 args and give it 20 without a type of an index error.

[@Jazz_FunkBass]

Tell me you didn't understand most of his talk without telling me you didn't understand most of his talk 😂

[@dark0sv]

@@Jazz_FunkBass Please elaborate. Thanks.

[@bottlewolf]

@@dark0sv The speaker proved his point that just because a frontend javascript developer can learn Rust (it's a high level language after all) , it doesn't mean that they have any of the skills or aptitude to work in critical system industries... Then he also adds many great points on why C/C++ are still the best choices & both languages are also being improved with every release.

[@fnizzelwhoop]

@@bottlewolf He also stressed that he doesn't know Rust, hasn't actually used it. His argument that "Rust might become useful in the future" might carry some weight if he had actually worked with it. Especially considering that people are building real projects with it every day, and have for years. I work in a high-assurance industry (not automotive, though), and we ship Rust code. This "it might be useful in the future" is just wishful thinking -- it's already useful. Like don't get me wrong, we have one product that has been running for almost a decade with all of its components written in C and it has zero production downtime bug reports (it failed a single fuzzying test in a customer's test environment, but it was not considered a risk in production), which we're pretty proud of. With that said, that level of stability required _a lot_ of work, and development slowed down more and more the larger the codebase got due to fears of introducing difficult-to-predict bugs. Our Rust ports, although just a few years old, has zero downtime bug reports as well, did not fail the fuzzying tests, and we do not feel scared to work on that code. He's right that a lot of safety standards mappings only exists for C. Though this doesn't mean Rust can't fulfill the requirements, it just means no one has done the work to produce all the appropriate documentation. (And frankly speaking, it might never reach the same parity as C, because these documents can take years to produce. And even if Rust would prove to be a much better language for all these application types, few would be willing to redo the work for Rust).

[@bottlewolf]

@@fnizzelwhoop There's not enough love from devs for Rust, it's like the Scala of the JVM... I think Zig & Carbon will dominate moving forward

[@qwertyman1511]

47:00 "[basically] all [vulnerabilities are] input validation failure". Then input validation takes on the scope of the entire program, and now we just made input validation basically the idea of the formal contract. A results in B and only B. Then C is bad at resulting in contracts as the programmer intended them if they had known the full scope and consequence of the program.

[@stzi7691]

Most of the time the problem is not C itself, it is libc and the broken parts of diverse handling APIs that maybe where a good fit in the 70s and 80s, but are now becoming a fever-dream. For instance strstr() and strtok() returning pointers. Some std-lib implementations nowadays have easier and less error-prone APIs, for instance in returning indexes instead of pointers everywhere limiting the use of pointers. Some parts even silently just add a 0-terminator when given a "string literal". This can get messy, and nowadays caching is your friend and APIs should not destroy it with unneccesary pointer mumbo-jumbo. Somebody from the CCC ("Chaos Computer Club"), the biggest whitehat hacker-club in Europe, funnily even stated: "What were they smoking?".

[@Heater-v1.0.0]

Having learned programming using assembler and ALGOL back in the late 1970's/early 1980s, having used compiled languages like Coral, Ada, Lucol, PL/M for safety critical (avionic), military and secure systems, having used C for a year in the PC application world, I was pretty shocked to find people starting to adopt C for embedded and safety critical systems. I could not understand how anyone could even think of deciding to use such an ill-defined language for what should be deterministic systems. So much undefined behaviour, implementation defined behaviour, etc. Hardly a language at all. Now that we have more rigorously defined languages with a priority of correctness built into their design I feel it is pretty much professional negligence to select C or C++ for new safety critical code today.

[@jamespong6588]

Portability, you write once and compile everywhere

[@Kobold666]

In the end, all languages are translated to machine code. Undefined behaviour only exists in documentation, all compilers and interpreters will do something well defined within their own code (they're not going to produce a random number because of an integer overflow). Correctness is what we learned and what we're paid for, it's the language's task to enable us to write correct code, not to prevent anyone from writing bad code. Same with human languages, you can insult people in the same language that is used to write beautiful poems. It's up to you to choose the right words, if you can't use a language without insulting someone, don't use it. That's my opinion as a 30+ years C programmer and assembly (reverse engineering) enthusiast.

[@mileselam641]

It's Assembly vs C all over again. The Assembly folks saying C will never be fast enough, never be flexible enough, never be reliable enough. They spent so much time honing their craft, making things easier and giving up control were synonymous with "bad". They needed to be forced, to retire, or die to allow the new workflow in. Met a guy a few years back that hadn't ever used git. Didn't trust it. Had his team checking every individual commit manually AFTER the merge to main. Not the diff from previous main to current main, no. Didn't trust the SHA despite us configuring the repo to only allow feature branch merges to main, not commits to main directly. Wasted a week of everyone's time on every deploy. To him, CVS and git were the same thing only a different name. Couldn't be convinced otherwise. Branching couldn't be trusted. This was in freaking 2019, not 1999.

[@Heater-v1.0.0]

@@Kobold666 Yes indeed. All compilers and processors/interpreters will do something with your programs, within the laws of physics. I'm not sure that is a helpful thought. They may well not generate random numbers on overflow, but they would be well within their rights to do so according to the C standard. Actual I bet you can find a C compiler and machine architecture that will produce essentially random numbers in response to the same request for a UB overflow. If we learned and are paid and expected, to produce correct code. Then why do you have a downer on languages that try to prevent you writing bad code? You don't want to write bad code so it's no matter to you, right? I first learned C in 1984, having used assembler and ALGOL before that, as such I don't understand how it is possible that you, with such long experience of C, would not welcome a language that automates away a lot of that tedious work of checking conformance with coding guidelines and safety standards all that work of running various code analysers and tests in the hope of catching our mistakes, etc, etc.

[@tobyengineers]

Truly "new" safety-critical code seems rare in industry, to me. Most "new" code still needs to compile and interop with the legacy code, and, if possible, new "safe" code should not only make that interop safer but also point out safety issues in the existing code. I'm new to the industry, but it truly seems to me that compiler design seems like the space in which to push forward safety in safety-critical spaces. A compiler that can non-intrusively add the ability to annotate lifetimes in existing C/C++ safety-critical code (*cough cough* Circle), if accepted more widely in the safety-critical community, would drive forward the industry far further than pining for a new language paradigm which requires complete rewrites of millions of lines of C/C++ code that exist at most companies.

[@billfrug]

He makes great points, not sure why he's getting so much flack.

[@maxkeller13]

This is disappointing to the point where I'd like to unsee it and get my time back.

[@Resurr3ction]

Indeed, having an hour long talk about Rust vs C and knowing nothing about Rust.

[@decathorpe]

Thanks for the warning 😅

[@mileselam641]

"Rust won't fix developer discipline." Wow, just wow. Rust never intended to fix developer discipline. The key point is you CAN'T fix developer discipline in the aggregate. This is where the C++ zealots missed the memo. In C++ you must be diligent, add in SANs to the workflow, patch in tools, manually manage your dependencies for building, etc. It requires a high level of discipline. Rust uses cargo to manage dependencies. Far less discipline necessary. No need to patch in SANs since the language and compiler already satisfy that niche out of the box. Far less discipline necessary again. C++ makes you focus on areas related to the language rather than your problem domain. Rust allows you to focus almost exclusively on your problem domain. If it compiles in C++, you've still got a long way to go. If it compiles in Rust, you're already 90% of the way there. Nothing can stop arithmetic or business logic errors, but those should be the only errors devs have to manage on their own. Use after free, race conditions for multiple threads, forgetting ownership on a struct member, etc. should be forbidden by the compiler, not "developer discipline". Developer discipline is how we got into this "security issues due to memory corruption mess" in the first place.

[@marcbotnope1728]

Wrong! Rust intends to make every developer Woke...

[@gtdcoder]

C is not the same language as C++. And the real danger is creating a false belief that a language or a compiler can guarantee safety and absolve the programmer of that responsibility. Rust, or at least it's community, is the most guilty of spreading that danger, making so many developers believe they dont need more skill, they can just rely on the language to save them.

[@CaptainOachkatzl]

​@@gtdcoder please provide statistics for A.) the claim, that rust developers "just rely on the language to save them", and B.) this is reflected in resulting errors/bugs in their software.

[@isitsaturdayalready1247]

@mileselam641 excellently summarized. So many people are missing the point, or end up arguing against themselves.

[@gtdcoder]

@@CaptainOachkatzl Or maybe you should provide evidence that C++ developers are "zealots" who "missed the memo".

[@ryleitdept]

modern C++ will still be no.1 and its keeps improving. Billions lines of code are waiting to be refactored. Looking forward for the static analysis and profiles to further emphasize resource safety 🎉.

[@Lorryslorryss]

I'd take a borrow checker over a charter any day of the week. I also think someone on the C standards board shouldn't be relying on the audience to tell them 12 year old news about memory safe programming. I don't think the wolves are circling as closely around C as they are around C++, but in the race to provide these necessary safety features the standardization communities are napping at the start line. This talk focuses a lot on what automotive industry wants. Except, I don't much care about what they want. They suck. When I last worked with them they did the standard old-style practice of releasing huge numbers of changes very infrequently. It was a compelling narrative back in the day: slow and steady wins the race and all that. But it's also empirically wrong. It's not safe to bundle up a year of changes to eg both the foot-break and hand-break and ship them together. We have know this for a decade (DORA). And we know that having a 3 year big-bang change to Rust would be dumb, but the dumb part about that plan isn't the "Rust" part. I find that industry terrifying and we shouldn't let them dictate what the future looks like. It's also strange to assume that Rust programmer are new people with no experience of what we've been doing in industry for many years. If you can learn C or C++, you can learn Rust. Language syntax isn't the hard bit of programming, Rust is based on the lessons learnt through our experience in C++ and you won't suddenly develop amnesia and forget what you've learnt about writing safe(-ish) code up to this point. Programmers are apparently too dumb to learn a new language, but smart enough to be up-to-date with all the latest opt-in-only static check flags.

[@vinterskugge907]

31:02 His comments around Java are outdated. People aren't using RMI / serialization nowadays, JSON is the norm. And anyone still needing to use object deserialization will have implemented whitelisting, which prevents the attack he describes.

[@krumbergify]

If you know modern C++ then Rust isn’t too hard to understand. Hire competent programmers and they will learn whatever they need to learn.

[@alfredomoreira6761]

What a disapointing talk. Even lying outright that rust would not prevent crowdstrike outage when in fact it would have prevented the outage.

[@Lorryslorryss]

I wouldn't say it like that, but yeah, the C standards board would benefit from learning a bit more about Rust. If I was doing integer bounds from a config file, maybe it would be prudent to use some of Rust's static checking. This is runtime overhead compared to get_unchecked (or indexing in C), but wouldn't have brought the world down: #![warn(clippy::indexing_slicing)] // or [lints.clippy] indexing_slicing = "warn" in the Cargo.toml fn main() { let numbers = vec![1,2,3,4]; println!("{:?}", numbers[2]); // this will warn on cargo clippy and suggest numbers.get(2) which returns Option }

[@qwertyman1511]

@@alfredomoreira6761 the bit about math error was false too. They were dragged to court for illegal vendor lock-in by geofencing repairs.

[@fnizzelwhoop]

Much of this talk is a strawman. No one is saying C and C++ should be "ejected from Earth", or whatever. Even staunch Rust advocates have no problem saying that C and C++ will be around for a very long time.

[@qwertyman1511]

They do say it in a way like nuclear waste will be around for a long time.

[@jamespong6588]

People underestimate how much critical and mature memory safe c and c++ code exists , just this one company I Know has millions of lines of code people use daily, it took decades to be composed, and it will take even more time in rust because it's slower to develop /write /compile, for no benefit

[@maxkeller13]

I've written my fair share of both c and rust and let me assure you, rust is one of the most productive languages I've ever written code in. Also, few people seriously demand rewriting existing code, I sure wouldn't, especially not immediately.

[@pookiepats]

Oh do they, good thing you’re here to represent the uneducated masses AND correct everyone 😂

[@jamespong6588]

@maxkeller13 I write c/ c++ code for over 20 years ....memory/type/thread safety is not even an issue. Like 0 , it's not even a consideration of an issue. It's really easy to manage memory if you follow the guidelines And use some tools or compiler flags that can do what rust does and better The most difficult thing is input validation making sure, your program can overcome bad input in every scenario, Rust doesn't even have a Good GUI for user interaction These types of problems need constant clean rebuild of projects and rust is just like million times slower than c in compiling So yeah

[@mrpocock]

Of course there's a ton of high quality, low bug, critical c and c++ or there. There are also critical bugs, even in that old code, and an embarrassing amount of that is memory safety-related. And none of those bugs can be even written in rust without using the unsafe keyword. I'm all for leaving old, working, thoroughly tested code alone. But new code should be written in languages where you can't use a foot-gun without very clearly telling the compiler that you are intentionally aiming and shooting a foot-gun.

[@jamespong6588]

@@mrpocock a) you can do that already better than rust in c/c++ by using guidelines testing protocols and compiler flags, if we couldn't the world would collapse., But you just don't like that, lso et's pretend we can't? B) what people who really fund and promote rust think they see, is the ability to do critical software (maybe) with cheap labor, that's all there is to it really.. it's something they are trying to do time and time again, remove the intelligence factor out of the equation of software. I think rust will introduce Boeing style design Flow bugs or crowdstrike events Memory related bugs are always in New code from cheap labor, We've seen this times and time again And we have a solution Let people who know what they are doing write code and Pay them But no , 7$/hour rust engineers

[@pookiepats]

38:39 exactly - but the crufty ass systems do not - and you don't wait to build the solutions of tomorrow, tomorrow.

[@paxdriver]

Tbh, 16:39 it'd be more compelling if it didn't come across so desperately defensive of C in the shadow of a looming crab butt. Thumbs up anyway for the topic and perspective, just not all that convincing imho.

[@SVVV97]

Imagine being confident enough to give an hour long (bad-faith) talk principally revolving around a language / ecosystem you evidently don't know about. Smh

[@RustIsWinning]

Typical C boomer 😂

[@krumbergify]

44:40 Well, software is a lot like cities. Some parts are really old, some are brand new. Some parts are really nice and some places should really be avoided. It is not strange at all. Change doesn’t affect everything at once and some things never changes :).

[@feldinho]

TLDW: C => Is very old; Rust => It's not so old.

[@fnizzelwhoop]

Off to a bad start. Guilt-by-association:ing interest in memory safe languages with five eyes is *highly* disingenuous.

[@qwertyman1511]

Well, interest by national and international bodies means you can't play pretend anymore. Real force is being.applied to resolve he disgreement.

[@pookiepats]

I would imagine the former CEO's of SEARS, Circuit City & Radio Shack would really enjoy this talk.

[@JoseColonTV]

So the man that works at a place called Woven gives a talk that would make Ned Ludd proud. Who says the Universe doesn't have a sense of humor?

[@BowBeforeTheAlgorithm]

I know this was a more informal talk, but it might help if you listed your bona fides before tearing into the topic. The timeline slide, showing how long C/C++ has been used in safety critical applications compared to Rust (along with all the tooling/standards) was spectacular. That really drove the point home. Really great talk.

[@Roibarkan]

Around 2:35: “I’m [the] conveneo of the C standards committee”

[@BowBeforeTheAlgorithm]

@Roibarkan Yes, I got that part, I would have liked to hear more about his automobile software experience and safety critical application experience earlier. He didn't mention that until more than halfway through the talk.

[@steveoc64]

Rust doesnt fix any of the problems it asserts that all other languages suffer from All it does is restrict what the programmer can tell the computer to do .... and then claim that all of these restricted things must be "unsafe" ... and only Rust knows the proper way with how to deal with them It's like telling everyone that there is an invisible fire breathing dragon that lives in those hills over there, and once convinced ... sells a special amulet of dragon protection to all the villagers. Even the Town Mayor has bought into the BS story about the invisible dragon, and mandated that everyone should buy the amulet. A large number of the dimwitted have bought into the scam, and for the last few years they have been hurling abuse at anyone that questions their invisible dragon narrative

[@josephsmith5110]

You may dislike Rust, but I think it is laughable to say it does not provide useful tools beyond memory safety. For instance, Rust did not invent tagged unions and pattern matching, but it is hard to deny that Rust's implementation of them has driven other languages to adopt them as well. As far as scams go, I think C++ may be the closest thing we have to that. Every couple of years, they wheel out new features and paradigms that have to be bolted onto the language, whether they clash with the previous designs or not. And Stroustrup will give talks with a "told-you-so" attitude and make hardly any concessions as to the flawed designs of the previous cycles.

[@RustIsWinning]

Old man steve yappin about dragons again. Meds + ♿️ my guy 😂

[@Abu_Shawarib]

that's the most unhinged criticism I've ever read about Rust. 😂

[@RustIsWinning]

@@Abu_Shawarib That's just grandpapa steve. Has nothing else to do but spread fake news which makes Zigooners look bad lmao

[@paxdriver]

27:07 Zig... Binaries... Containers... How is it an argument?