Hacker News Reader

> Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any Progress

Have you seen the hammers available in 2022? Not shitty $10 at the DIY store hammers, the kind professionals use? They're making hammers out of Titanium. They're engineering the hammers to produce the best trade offs between striking force and rebound, to deliver a tool that's more effective but hurts less to use for a full day's work.

People have continued to fail to write secure and performant applications in C at an unacceptable rate.

Furthurmore, in 2022 large scale professionals (and in this allegory, kernel devs are that kind) are more likely to use industrial hammers which have nothing in common with the hammers of the 18th century apart from the name and their basic function of hammering.

> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.

No one is advocating for writing the kernel in “poorly-written Rust”. This whole post is one giant, obvious straw man.

It's not entirely a strawman. The steelman version:

When replacing battle-tested code with newly-written code, you're going to encounter new bugs. Guaranteed.

And as always when this comes up, Rust is currently slated to be used for new development. Even putting aside the safety aspect, Rust has a lot of nice high level language features without too much overhead.

If the code is only battle tested you have a problem. If you did the correct thing and have written the actual tests for each of the lessons learned nothing stops you from porting these over to Rust.

If you don't have the tests you just listed another reason why using a language with better safety guarantees that will not let broken things compile is a good idea.

The way I see it even battle tested old code can become a liability, if it's surrounding and dependencies change.

It's often impractical to fully test every single aspect of all code. An example that I've seen several times is bottlenecks in unexpected places. Once was due to false sharing, another due to worse standard library QoI.

There’s some merit to “replacing battle tested code with new code”, but (1) a straight port can significantly mitigate these risks and (2) the parent explicitly compared “poorly-written Rust” with “expertly-written C”, so I think your steelman is far too charitable (I’m all for charitable interpretation but the charitable interpretation must bear some semblance to the original).

I agree with you on all counts.

I think the only thing I can say wrt poorly/expertly written is I haven't met very many people capable of writing top-quality Rust (most are "I've used it for a side project or two"), whereas my professional network is filled with C experts.

I expect this is due to the types of jobs I work, but the point stands: if we were to try to replace C with Rust we would likely get at most "journeyman" quality.

Even if the average C developer is more expert than the average Rust developer, I don't think the kernel will be developed by an average developer of either language.

Nobody is claiming Rust is a silver bullet, least of all Rust itself which is quite explicit about this.

What it does, however, is assure that an unsafe-free program will not contain any of a certain class of bugs, including invalid memory accesses or data races.

At the same time, it is an objective fact that a huge proportion of serious exploits and vulnerabilities are caused by exactly this kinds of bugs, no matter how much people like you go "just write correct code bro". Formal verification is the way forward and Rust is an excellent first step.

As a bonus, even if you wrapped your whole program in `unsafe`, Rust is a miles better systems programming language than C, in terms of features (imho of course).

It's fun that you mentioned systemd! In it early years, it was notorious for its... lack of robustness and correctness, let's call it so.

An it definitely did have its fair share of dangerous issues [1] which would likely not happen if a safer language were used to write it.

1: https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

> Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation.

Obviously you have never experienced or oversaw what goes in the linux kernel mailing list.

Yes, for the average user Linux is rock solid, but behind the curtains lies the countless sweats of kernel contribuitors fighting the bugs, regressions, memory leaks and crashes.

> The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver.

I have done this. I don't anymore, but my entry into the software world was exploitation of C code and I was particularly interested in the Linux kernel. I'm not really an expert on it, but I've certainly worked with many. Here's an example of some of the work my company has done, which I was not the main driver for but was involved [0]. You'll note the zero days and n days in the Linux kernel. I really don't think compiling a kernel driver is very hard, uncommon, or relevant experience here.

We also attacked Firecracker, a Rust project, and I'd say I'm quite experienced in the language.

> Linux, systemd, grub are all written in C and continue to have fewer flaws

If by "Linux" you mean the Linux kernel, absolutely not, and I can't imagine anyone informed would say that. Linux has tons of bugs all the time.

> The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model

A few things:

1. This isn't a zero sum game. Some people are working on making existing kernel code safer, some people are working on Rust, some people are working on new approaches to access control.

2. If an attacker can exploit the kernel your security model doesn't matter, they'll bypass the thing enforcing it.

3. Rewriting the entire kernel's privilege concept is a sort of hilarious ask since it's completely counterproductive (there are tons of powerful access mechanisms in the kernel already) and would be extremely costly.

> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.

lol sorry, this just really gets me. The Linux kernel is not expertly written C, nor is it being vetted for decades. That's just... so wrong. The kernel codebase is riddled with flaws that are often exploitable. You're just... so so wrong on this.

Further, auditing Rust code for memory safety errors is trivial compared to C. As we showed in our post on Firecracker we could basically just "grep forunsafe" and then manually trace the code from that point.

> Iterative improvement has ALWAYS been the answer over throw everything away and start fresh.

No one is throwing anything away, you obviously are very confused about what Rust in the kernel means.

> and people will continue to successfully write secure and performant applications in C.

At first glance, this is a hilarious statement, but it ultimately makes me sad that developers are so ignorant about computer security that they'd feel ok saying something so obviously wrong to anyone who knows wtf they're talking about.

> Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any Progress

Terrible analogy.

[0] https://www.graplsecurity.com/blog

Apparently many C users aren't aware that lint exists since 1979.

Hammers are, like, sooo unsafe though!

As someone who does SMD work on hardware using microscopes I would not be able to fix these PCBs (or that analogy) using a hammer.

This is like saying "Uhh mountains are unsafe, I don't get why they put up a handrail at that crowded vantage point over there".

Whether a tool/safety mesure is appropriate is always is about context. I have literally met zero people who work on security or safety critical (e.g. embedded, networking, ...) C code who do not welcome the guarantees Rust brings. It is a complete no-brainer. The ones that complain are the I am a genius who never makes mistakes"-crowd. So precisely the people you should never* let anywhere near anything safety critical.

I write C and I delved into Rust and I can tell you that I trust a vomitted out piece of Rust I wrote more than a piece of C I carefully vetted — and there are rational resons for that. The things that can go wrong at any given point in a C code are more, the ways they can go undetected are more and so on.

Anybody who claims otherwise has not put in the legwork themselves.

Rust is incredibly rigid and stringent by default and if something compiles you can be sure that it now just needs it's logic tested (which is a joy to do in that language).

I dabble in Rust, no genuine dislike of the language but the awkward syntax is what keeps me writing modern C++ as a middle-ground between the scary badlands of archaic C and the triple wrapped rigid Rustlands.

Though, as you mention, if required I will gladly write it if the situation warrants such a tool. Any suggestions for idiomatic testing?

C was already outdated before being released, when compared with the security capabilities from PL/I, BLISS, Mesa, NEWP.

Even Modula-2, released in 1978, has safety features that are yet to be part of C23, about 40 years later.