I'm starting to get sick of the neverending "rust good, c bad" sentiment on HN.
Bugs occur in rust code too. It's not a silver bullet to fix all problems associated with software development. Each language will have its own set of issues and quirks. It's easy to pick on C because it's been around far longer than most things. Give it 40 years and people will be saying "rust bad, new thing good".
That's not an argument for sticking with the old programming language that apparently is impossible to use safely (if you think that you can use it safely, what makes you think that you are better than the all-star cast of C programmers that have contributed CVEs over the years?). There were better alternatives to C in the 80s, there most certainly are better alternatives to C these days. I'm so sick of the Uncle Bob school of thought that all that is needed for better software engineering is discipline. If we haven't managed to impose that discipline yet after five decades, why would we believe that it will magically appear in the future? My guess is that a programmer that had the requisite mythical discipline would gravitate to programming languages like Rust or Ada anyway, because that developer wouldn't mind tooling that helped with it.
IIUC, this is just another case where unprivileged users are now allowed to do what once was allowed only to superusers. As long as only root was allowed to add net filter rules, what did it matter if they could do bad stuff? They're root already!
Now, in places where security didn't matter, it suddenly does. Thus, it's not about bad coding habits, but inadequate care in extending privileges to untrusted users. The code should have been cleaned up first.
No it's both. There's a ton of issues like overflows in the kernel but people have prioritized looking at unpriv -> kernel or unpriv -> root, and not root -> kernel. Now many of the root -> kernel vulns are unpriv -> kernel.
The issue is still the code, it's just the impact that has changed.
> Bugs occur in rust code too. It's not a silver bullet to fix all problems associated with software development.
Not being a silver bullet doesn't mean it's not an enhancement.
Of the two bugs mentioned in this announcement, one is an uninitialized local variable, which is allowed in C but not allowed in many other languages (like Java or Rust). The other one is an implicit cast from an enum to a signed integer; in languages where this particular kind of cast must be explicit, not only it's easier to see when it's a signed integer, but also it's more probable that it would be cast to an unsigned integer instead.
> Each language will have its own set of issues and quirks. It's easy to pick on C because it's been around far longer than most things.
It's easy to pick on C not because it's been around for longer than most other popular programming languages, but because it has a larger amount of footguns. It's true that Rust has plenty of quirks of its own, but most of them will not cause security issues.
Bugs absolutely occur in memory-safe languages. Log4j was a thing.
But a huge number of exploitable vulnerabilities are completely prevented by memory-safe languages. We've spent decades trying like hell to come up with other solutions to prevent these kinds of bugs in languages like C and utterly failed. Nobody knows how to write C or C++ programs of any meaningful scale free from memory safety errors without calling for total rewrites and ballooning budgets by 50x.
> Give it 40 years and people will be saying "rust bad, new thing good".
Of course. Rust will have systemic problems and some new thing will mitigate those problems. This is a good thing, not a bad thing. Why should there be any expectation that a language be the desired language for engineering projects until the end of time?
I never said new languages are a bad thing. I only made the point that people mindlessly bandwagoning and repeating the same talking points endlessly is an annoying thing.
Is it mindless bandwagoning? "Memory unsafe languages are an industry-wide emergency" should be a more-or-less constant discussion in the industry, IMO.
Memory safety is certainly a topic worth talking about, but on HN it always ends with the same conclusion: use rust. Is that really the only solution?
I've never seen anything quite like the rust community. They're hell-bent on recruitment. More so than any other language platform I've seen. Personally, I'm just sick of it. It's fine if you don't feel the same way. I was just voicing my frustrations.
> Memory safety is certainly a topic worth talking about, but on HN it always ends with the same conclusion: use rust. Is that really the only solution?
No. Of course not. It appears to be the most common solution and community matters, so I suspect it will end up being a dominant solution. But you can (mostly) solve this problem with completely orthogonal approaches. Getting all of your code to run on x86 with MTE enabled is another approach that prevents entire classes of problems.
I'm not a member of the Rust community. My actual work focuses more on the Log4j-style stuff than buffer overruns. But I really don't know what people who are upset about the state of memory safety can do to prevent the "ugh, here come the rust nerds" complaints other than simply never raising the problem - which obviously isn't the right approach.
10 years ago the C and C++ community complained about a different thing whenever memory safety came up. "UGH, stop talking about GCed languages. GC advocates are such aggressive recruiters." Now the complaints have just reoriented themselves.
No it isn't the only option, plenty of languages are available, specially if automatic memory management is an option on the specific deployment scenario.
Usually we land on Rust only discussions, due to more active advocacy that should known better to avoid tiring the audience, or by defensive attittude from unsafe language folks that push back every single reference to write secure software as a sales pitch for Rust.
I always mention secure system programming languages going back to 1958. Don't remember Rust being that ancient, and have plenty of critical remarks about Rust as well.
Seriously! Kinda like those food services people who harp on and on about gloves. Clean gloves prevent this, clean gloves solve that. And they're not content to just use gloves themselves. They keep evangelizing to recruit everyone to their practice.
It gets annoying to those of us who know how to do safe food prep without wearing gloves.
I'm starting to get sick of the neverending sentiment that Rust is the only option to write secure software, and any remark for security gets dismissed as Rust sales pitch.
Plenty of languages to chose from to replace C and its kind.
Of course there are. Swift might be a viable alternative. There are also up-and-coming languages like Zig. But, like it or not, Rust has the best combination of features, mindshare, and community to make it a viable path for businesses today or in the very near future.
Sure, Ada/SPARK is another option. Listing out the various potential choices people can make is not especially interesting to me. I don't personally care about Rust. I care about people taking action to solve a frankly embarrassing problem in our industry.
That would, depending on implementation, either have limited impact (if it only applied in the context of a commercial relationship), or destroy FOSS (if it didn't).
The usual argument, health inspections don't destroy the little business selling sandwiches on the corner, or street regulations and those doing their own home made car.
Plenty of languages far better suited for most use cases, yes we have that. But to replace C, there are not that much candidates. I don’t mean Rust is such a candidate.
Maybe Zig is currently the closest thing to such a candidate, but it doesn’t even pretend to aim at this, andalign with the "C ABI as interoperation modus for foreign function interface" policy, like the rest[1] of programming languages.
From 1958 up to the mid-1980's many OSes were written in something else other than C, and in the 15 years that preceded it there were approaches beyond pure Assembly.
Granted it is a matter for the market to be willing to move beyond it, and the OSes written in it, but the matter isn't technical per se, rather economical, political, human behaviours,...
Yes, we totally agree that this is not a purely technical issue. This is not completely unrelated, inertia here is also fed by technical considerations.
while rust probably wouldn't have caught this bug, it is worth noting that the class is memory bugs C and C++ have are especially pernicious. bugs caused by manual memory allocation in these languages are often highly exploitable, and come from a common and necessary part of the language. As a result you end up with somewhere around 70% of security vulnerabilities being caused by a feature that just doesn't exist in other languages. the reason Rust gets so much hype is that it removes the last excuse of C/C++ (GC time).
But do your users prefer C? For software engineering to be a professional discipline, we really need to make choices based on the product outcome rather than based on what feels fun to program.
I imagine they do. If they didn't, they wouldn't be using it. They would instead be using some equivalent piece of software written in a trendy language.
The large majority of users cannot make well informed security risk decisions like this. Engineers should do the right thing and help these users. In the same way, I can't make some meaningful risk assessment for using a bridge or riding an elevator. Civil Engineers don't just get to say "well, if users are concerned about the safety of my bridge then they can make a different choice so I'm going with the stuff I personally like working with." Why do Software Engineers get away with this?
Outside of small hobbyist projects, the industry has an obligation to provide users with safe software.
1. Start new projects intended for production that have nontrivial security threats in C or C++
2. Not have a plan to categorically prevent memory safety errors in legacy codebases over the next decade or so, whether that be by transitioning to new languages or by applying rigorous hardware-level memory tracking
Yeah can you imagine if it actually mattered if companies made choices that they knew were inevitably going to lead to zero-click exploits on internet-enabled devices? Somebody sitting down to write a media decoder in C today knows that this means a steady stream of exploits harming their customers.
I don't think your argument is all that strong. Memory bugs are not equivalent to vulnerabilities. To get to a security vulnerability you first need a logic bug that makes incorrect assumptions about the program state, the hardware, the API, the input, or something else.
Also, what is so bad about crashing bugs? To me, as a programmer, they're very good news. It means you found a bug, you (hopefully) have a crash/log to analyze, and more importantly it means the program didn't just silently continue executing and corrupt state/data without anyone knowing.
Memory bugs are often vulnerabilities. Efforts to classify them as “very unlikely to be exploited” almost always end up turning into “someone with sufficient interest can exploit this”.
Most languages other than C/C++ (eg rust) do bounds checks by default. Also, C is pretty much the only language that uses null terminated strings which are a very common source of overflow.
> Give it 40 years and people will be saying "rust bad, new thing good".
Why is this an argument? Yeah, personally, I'd be very happy if in 40 years there's something better than Rust. It's been a solid few decades of C prominence, and moving from lang to lang should of course not be something that happens every few years. But on the scale of 40 years? I'd hope we aren't all still using something made today in 40 years, let alone a few years old.
Who said it was an argument? It's merely an observation of what I've witnessed here on HN: endless sentiment about rust and how everything should have been written in it.
The linux kernel was initially written 30+ years ago. Rust didn't exist. C did. Complaining about it being written in C does nothing to benefit anyone.
> I'd be very happy if in 40 years there's something better than Rust.
> Complaining about it being written in C does nothing to benefit anyone.
For what it's worth, I agree. It's already written, so rewrite it yourself or use a Rust-based OS or work on Rust internals/specs in order to improve the language.
But I also believe that sometimes it can be a legitimate discussion. It can serve as a reminder that often these languages have footguns that even experienced developers that insist they can use C effectively will eventually fire off.
There are ways to manage the risk of buffer overflow in C without changing the language, but C programmers don't want to do it, because traditionally they believe they need to be brave and do it the hard way.
One could even add basic string and array types, so that the ecosystem could optionally slowly move away from pointer based types, but it will never happen.
There's no reason not to. We'll just have to suffer through thousands more HN posts saying "new thing better, they should have used the new thing" whenever somebody finds a new kernel vulnerability.
It does nothing to help the situation. It's just complaining from people who won't be satisfied until all software is written entirely in rust. Why not contribute to the kernel and try to fix some bugs instead?
I believe there will always be some people cheering from the side, not directly contributing. But they're a useful barometer for the current weather. And for some time now we knew a change is coming. Who knows if the Rust kernel modules would've happened without so many people reminding us that we don't have to suffer from the same bug classes forever.
> It's just complaining from people who won't be satisfied until all software is written entirely in rust.
I don't care what memory safe language they choose, rust is just the obvious choice for this domain.
> Why not contribute to the kernel and try to fix some bugs instead?
Who says we don't? My company contributed a 0day to the Linux kernel just recently.
Maybe we're all saying "new thing better" because we're sick of people writing garbage software and making users unsafe? Maybe we actually know better than you?
Bugs occur in rust code too. It's not a silver bullet to fix all problems associated with software development. Each language will have its own set of issues and quirks. It's easy to pick on C because it's been around far longer than most things. Give it 40 years and people will be saying "rust bad, new thing good".