Something that in often missed when talking about improving software security/reliability, is how bloated our software has become to accomplish basic functionality. The more code we write/use, not...
Something that in often missed when talking about improving software security/reliability, is how bloated our software has become to accomplish basic functionality.
The more code we write/use, not forgetting libraries (one of the reasons log4j was so devastating), the bigger the attack surface. Most bugs are a result of the execution state not being exactly what you think it is*. The more complex the codebase, the harder it is to conceptualise what the execution state is.
This also means troubleshooting and feature improvements are harder and take longer.
*I can't claim this is original, it's from an internal John Carmack email talking about Armadillo Aerospace. But if Carmack says it, I'm inclined to believe him
I think there will be a lot of this. Rust is probably the first language that comes to mind for a lot of people when they see this, and I doubt many people will see this who don't know about Rust....
I think there will be a lot of this. Rust is probably the first language that comes to mind for a lot of people when they see this, and I doubt many people will see this who don't know about Rust. This document will likely increase adoption of Rust, but I doubt it will be much faster than if it hadn't mentioned Rust explicitly.
They do in fact cite Rust specifically as a memory-safe language that meets all the criteria laid out in the document. So here’s hoping that it increases adoption!
They do in fact cite Rust specifically as a memory-safe language that meets all the criteria laid out in the document. So here’s hoping that it increases adoption!
President Biden’s National Cybersecurity Strategy outlines two fundamental shifts: the need to both rebalance the responsibility to defend cyberspace and realign incentives to favor long-term cybersecurity investments. In this report, the case is made that the technical community is well-positioned to drive progress on both strategic goals. First, in order to reduce memory safety vulnerabilities at scale, creators of software and hardware can better secure the building blocks of cyberspace. This report focuses on the programming language as a primary building block, and explores hardware architecture and formal methods as complementary approaches to achieve similar outcomes. Second, in order to establish accurate cybersecurity quality metrics, advances can be made to address the hard and complex research problem of software measurability. This report explores how such metrics can shift market forces to improve cybersecurity quality across the ecosystem.
I'm suprised Ada wasn't mentioned. It is still under active development, and my understanding is that it was basically the first "safe" systems language with SPARC.
I'm suprised Ada wasn't mentioned. It is still under active development, and my understanding is that it was basically the first "safe" systems language with SPARC.
Just found this article that responds to this release. I don't know enough to comment on it: https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/
Just found this article that responds to this release. I don't know enough to comment on it:
The author is correct that memory safety vulnerabilities aren't the only vulnerabilities, and it's possible to write C or C++ in a way that ensures you don't get memory errors. Except memory...
The author is correct that memory safety vulnerabilities aren't the only vulnerabilities, and it's possible to write C or C++ in a way that ensures you don't get memory errors.
Furthermore, while you can technically write memory-safe C/C++, it's very tedious and hard to get right. It involves formal verification (which makes solving borrow-checker issues feel like cakewalk) and/or using a subset of the language which is so small, you can barely write anything. The author severely underestimates how pervasive C/C++ footguns are; his example of a "safe" container, std::string, has at least one memory-safety footgun of its own! The entire point of Rust's strict, unintuitive rules is that developers can't be trusted to write safe code on their own, and there are so many seemingly-innocuous ways to get memory corruption; Rust's annoying rules are what's necessary to write truly-safe, high-performance software.
To the author's credit, and ironically something I don't think he addressed, the discussion around this seems to be missing that Rust is far from the only memory-safe language. In fact, most languages being used today make it so the average developer has to go out of their way to cause memory corruption: I'm talking about Go, Java, Python, JavaScript, Lua, Swift, Haskell, and any other language with garbage collection or some other form of automatic memory management. These languages achieve safety by taking memory control away from the user and managing it themselves (hence "automatic memory management"), and inserting guards before reads, writes, and other potentially-unsafe operations.
The drawback is that automatic memory management and guards cause extra overhead, so C++ and Rust are preferred for code that needs to run as fast as possible. But I believe that it's rare* that speed is so important, this overhead is a real issue; at least, more rare than the cases where C/C++/Rust are chosen. Modern computers are fast, and well-written Swift/Go/Java is almost as fast as well-written C. Even if your program needs to be efficient, it's usually only a small part that does the heavy lifting, which can be written in a fast language while the rest is written in a scripting language; this is what most game engines (e.g. Unity, Godot) and neural networks (e.g. PyTorch) do.
* Relatively. I can think of a few categories of programs which are exceptions, and I'm sure there are many programs written in these categories.
I disagree that most programmers don't need to worry about the performance of their code. Computers are faster than they have ever been, true, but software is also as slow and unreliable as it has...
I disagree that most programmers don't need to worry about the performance of their code. Computers are faster than they have ever been, true, but software is also as slow and unreliable as it has ever been.
Casey Muratori has a great talk about why performance is relevant to the average programmer - his background is game engine architecture but he shows that other industries spend a lot of time and money chasing performance for business reasons. https://youtu.be/x2EOOJg8FkA
Jon Blow has an interesting talk about how slow/buggy modern software has become and why it's a problem. He's a game designer/programmer but similar to Casey, he discusses how it impacts the broader software industry. https://youtu.be/ZSRHeXYDLko
A few points: Code doesn't have to be written in C/C++ or Rust to be performant. It's true that in practice, well-optimized C++ or Rust code is faster than well-optimized Python or JavaScript; but...
A few points:
Code doesn't have to be written in C/C++ or Rust to be performant. It's true that in practice, well-optimized C++ or Rust code is faster than well-optimized Python or JavaScript; but well-optimized Python and JavaScript code is fast. I'd argue the excessive slowness of modern software isn't because of the language, but because of other factors like performance-draining abstractions and bloat. If your basic GUI-based desktop app, 2D/low-poly 3D game, or website can't function with zero lag on a modern computer, it's not because of the language; and in fact, an inefficient C++ or Rust implementation can be even slower than an efficient Python or JavaScript one. This is reinforced by how slow software also tends to be buggy (and vice versa), but C++ certainly doesn't prevent prevent more bugs than say, Java or TypeScript (maybe Rust does, and maybe both beat untyped Python or JavaScript; but back to the argument for automatic memory management, the entire point is that it effectively eliminates memory-related bugs that C and C++ keep).
The first source focuses on big companies rewriting their software in faster languages. But importantly, all of them are big companies with already-successful products, and all of them started with a small prototype in a dynamic language. In fact, I believe the correct way to write great software is to start with a prototype written in something like Kotlin which prioritizes flexibility over performance, and only rewrite in something like Rust once the concept is solidified if performance becomes an issue. Because if you write the initial app in C++ or Rust, you have to think about memory or lifetimes alongside your core app's architecture; this makes development slower, discourages important-but-big changes, and makes you end up with a more convoluted product that you may just rewrite again anyways.
Some languages, like JavaScript and Python, have design decisions which create much more overhead than their automatic memory management and runtime guards: both JavaScript and Python are interpreted (with optional JIT compilation) and don't have a static type system. In general, code written in Swift, Java, or OCaml performs much closer to C than it does to JavaScript or Python (here's a comparison of C/Java/Python programs with a simple benchmark, although benchmarks don't really reflect real-world code).
The bottom-line is that there's a lot of "low-hanging fruit" when it comes to slow software. Firstly, time complexity and expensive redundant computations will destroy software performance no matter what language. Then there's reducing allocations, swapping inefficient libraries for better or home-grown ones, and other "mid-level" optimizations, where in a language like C++ or Rust is probably easier, but in Java or JavaScript it's still possible. All these optimizations affect performance much more than removing the overhead given by automatic memory management and runtime guards. Eventually you may get to a point where removing the GC and guards is necessary; but people very frequently choose C++ or Rust prematurely, for a project which will never reach that point.
Slow in relation to what it's doing, sure. Slow in relation to human time frames, "eh?". And I see people claim that modern software dev is somehow more unreliable, but I remember my computer...
Slow in relation to what it's doing, sure. Slow in relation to human time frames, "eh?".
And I see people claim that modern software dev is somehow more unreliable, but I remember my computer crashing on a whim in the 90s-00s and god forbid I risked having multiple programs open at once. These days it's pretty trivial to have most of what you want open and things don't tend to take down the entire OS when they crash.
Don't get me wrong, JS is practically a greek myth levels of ironic when it comes to the problems its has caused, and I do think is one of the biggest examples of the problems with how coding is approached, but at the same time there's plenty of other languages that do a good job of encouraging proper coding styles and are "performant enough" (and typescript is now a thing). And that's before we get into things like Rust which aren't exactly widely adopted yet (at least in comparison to C/C++) which are more than performant enough(although rust does have it's own issues like any lang). I personally use F# and have never hit a "man if only I could make this faster" point that wasn't just because I was using the wrong data structure for something.
But the real meat of the discussion always boils down to "do you need a few extra ms, or hell even seconds or minutes, or do you need to prevent some memory unsafe error that will compromise EVERYTHING".
Coding development is NOT going to become safer at the cost of time. God knows the majority of code is pushed out on deadlines with the people writing it not always having the context for what's going on. We've gotten better at doing test driven development, but the whole point of memory managed and type safe systems is to also help keep safety without adding extra overhead to development time frames that companies and clients refuse to accept. Letting the compiler do the majority of the heavy lifting is a much better method than "just don't hire bad coders or have bad practices", and hell is more in the spirit of coding anyways.
You'll always see things like C/C++/Assembly in the top of the line performance areas (military especially) but the vast majority of applications gain nothing but potentially massive weaknesses and slower development from using them. How many complete remote code compromises have to occur before we really ask ourselves if this is worth whatever supposed performance there was.
I'd suggest watching the Casey Muratori talk I linked, the evidence he provides directly contradicts your statements that it doesn't apply or isn't worth it. Can you provide proof of your claim?...
You'll always see things like C/C++/Assembly in the top of the line performance areas (military especially) but the vast majority of applications gain nothing but potentially massive weaknesses and slower development from using them.
I'd suggest watching the Casey Muratori talk I linked, the evidence he provides directly contradicts your statements that it doesn't apply or isn't worth it. Can you provide proof of your claim?
But the real meat of the discussion always boils down to "do you need a few extra ms, or hell even seconds or minutes, or do you need to prevent some memory unsafe error that will compromise EVERYTHING".
What makes this an either/or choice? A good software engineer with intimate knowledge of what the computer is actually doing in response to their code will produce software that is both fast and secure.
I'll refer back to my other comment where I referenced John Carmack (another great programmer who writes fast code whose advice you should take seriously) - "Most bugs are a result of the execution state not being exactly what you think it is."
Something that in often missed when talking about improving software security/reliability, is how bloated our software has become to accomplish basic functionality.
The more code we write/use, not forgetting libraries (one of the reasons log4j was so devastating), the bigger the attack surface. Most bugs are a result of the execution state not being exactly what you think it is*. The more complex the codebase, the harder it is to conceptualise what the execution state is.
This also means troubleshooting and feature improvements are harder and take longer.
*I can't claim this is original, it's from an internal John Carmack email talking about Armadillo Aerospace. But if Carmack says it, I'm inclined to believe him
I wonder if the explicit mention of Rust will boost its popularity. Would be nice.
Learning a bit about Rust has been on the To Do list for a while. This might be the kick I needed to jump in.
I think there will be a lot of this. Rust is probably the first language that comes to mind for a lot of people when they see this, and I doubt many people will see this who don't know about Rust. This document will likely increase adoption of Rust, but I doubt it will be much faster than if it hadn't mentioned Rust explicitly.
They do in fact cite Rust specifically as a memory-safe language that meets all the criteria laid out in the document. So here’s hoping that it increases adoption!
Abstract:
I'm suprised Ada wasn't mentioned. It is still under active development, and my understanding is that it was basically the first "safe" systems language with SPARC.
Yeah, and it was developed for the DoD in the first place.
Just found this article that responds to this release. I don't know enough to comment on it:
https://hackaday.com/2024/02/29/the-white-house-memory-safety-appeal-is-a-security-red-herring/
The author is correct that memory safety vulnerabilities aren't the only vulnerabilities, and it's possible to write C or C++ in a way that ensures you don't get memory errors.
Except memory safety vulnerabilities are very common: an analysis by Microsoft in 2019 concluded that over 70% of their CVEs were memory safety issues. And it doesn't matter whether memory unsafety is the worst cause of exploits; it's the cause of some high-profile exploits, so when you're writing secure software, it's something you care about.
Furthermore, while you can technically write memory-safe C/C++, it's very tedious and hard to get right. It involves formal verification (which makes solving borrow-checker issues feel like cakewalk) and/or using a subset of the language which is so small, you can barely write anything. The author severely underestimates how pervasive C/C++ footguns are; his example of a "safe" container,
std::string, has at least one memory-safety footgun of its own! The entire point of Rust's strict, unintuitive rules is that developers can't be trusted to write safe code on their own, and there are so many seemingly-innocuous ways to get memory corruption; Rust's annoying rules are what's necessary to write truly-safe, high-performance software.To the author's credit, and ironically something I don't think he addressed, the discussion around this seems to be missing that Rust is far from the only memory-safe language. In fact, most languages being used today make it so the average developer has to go out of their way to cause memory corruption: I'm talking about Go, Java, Python, JavaScript, Lua, Swift, Haskell, and any other language with garbage collection or some other form of automatic memory management. These languages achieve safety by taking memory control away from the user and managing it themselves (hence "automatic memory management"), and inserting guards before reads, writes, and other potentially-unsafe operations.
The drawback is that automatic memory management and guards cause extra overhead, so C++ and Rust are preferred for code that needs to run as fast as possible. But I believe that it's rare* that speed is so important, this overhead is a real issue; at least, more rare than the cases where C/C++/Rust are chosen. Modern computers are fast, and well-written Swift/Go/Java is almost as fast as well-written C. Even if your program needs to be efficient, it's usually only a small part that does the heavy lifting, which can be written in a fast language while the rest is written in a scripting language; this is what most game engines (e.g. Unity, Godot) and neural networks (e.g. PyTorch) do.
* Relatively. I can think of a few categories of programs which are exceptions, and I'm sure there are many programs written in these categories.
I disagree that most programmers don't need to worry about the performance of their code. Computers are faster than they have ever been, true, but software is also as slow and unreliable as it has ever been.
Casey Muratori has a great talk about why performance is relevant to the average programmer - his background is game engine architecture but he shows that other industries spend a lot of time and money chasing performance for business reasons. https://youtu.be/x2EOOJg8FkA
Jon Blow has an interesting talk about how slow/buggy modern software has become and why it's a problem. He's a game designer/programmer but similar to Casey, he discusses how it impacts the broader software industry. https://youtu.be/ZSRHeXYDLko
A few points:
The bottom-line is that there's a lot of "low-hanging fruit" when it comes to slow software. Firstly, time complexity and expensive redundant computations will destroy software performance no matter what language. Then there's reducing allocations, swapping inefficient libraries for better or home-grown ones, and other "mid-level" optimizations, where in a language like C++ or Rust is probably easier, but in Java or JavaScript it's still possible. All these optimizations affect performance much more than removing the overhead given by automatic memory management and runtime guards. Eventually you may get to a point where removing the GC and guards is necessary; but people very frequently choose C++ or Rust prematurely, for a project which will never reach that point.
Slow in relation to what it's doing, sure. Slow in relation to human time frames, "eh?".
And I see people claim that modern software dev is somehow more unreliable, but I remember my computer crashing on a whim in the 90s-00s and god forbid I risked having multiple programs open at once. These days it's pretty trivial to have most of what you want open and things don't tend to take down the entire OS when they crash.
Don't get me wrong, JS is practically a greek myth levels of ironic when it comes to the problems its has caused, and I do think is one of the biggest examples of the problems with how coding is approached, but at the same time there's plenty of other languages that do a good job of encouraging proper coding styles and are "performant enough" (and typescript is now a thing). And that's before we get into things like Rust which aren't exactly widely adopted yet (at least in comparison to C/C++) which are more than performant enough(although rust does have it's own issues like any lang). I personally use F# and have never hit a "man if only I could make this faster" point that wasn't just because I was using the wrong data structure for something.
But the real meat of the discussion always boils down to "do you need a few extra ms, or hell even seconds or minutes, or do you need to prevent some memory unsafe error that will compromise EVERYTHING".
Coding development is NOT going to become safer at the cost of time. God knows the majority of code is pushed out on deadlines with the people writing it not always having the context for what's going on. We've gotten better at doing test driven development, but the whole point of memory managed and type safe systems is to also help keep safety without adding extra overhead to development time frames that companies and clients refuse to accept. Letting the compiler do the majority of the heavy lifting is a much better method than "just don't hire bad coders or have bad practices", and hell is more in the spirit of coding anyways.
You'll always see things like C/C++/Assembly in the top of the line performance areas (military especially) but the vast majority of applications gain nothing but potentially massive weaknesses and slower development from using them. How many complete remote code compromises have to occur before we really ask ourselves if this is worth whatever supposed performance there was.
I'd suggest watching the Casey Muratori talk I linked, the evidence he provides directly contradicts your statements that it doesn't apply or isn't worth it. Can you provide proof of your claim?
What makes this an either/or choice? A good software engineer with intimate knowledge of what the computer is actually doing in response to their code will produce software that is both fast and secure.
I'll refer back to my other comment where I referenced John Carmack (another great programmer who writes fast code whose advice you should take seriously) - "Most bugs are a result of the execution state not being exactly what you think it is."
http://number-none.com/blow/john_carmack_on_inlined_code.html