Re: The Case for Rust (in any system)

Alan,

I agree, indeed, that we need better languages in the FreeBSD system. C has 
done its job very well in the last 50 years, and I think it will still be 
useful in the next 50. We can’t just “rewrite” everything, but we can rewrite the 
critical stuff.

My question, however, is “Why Rust?”. Rust is not the only memory-safe language 
out there. There are far better options for an Operating System like FreeBSD, 
where the language itself is way more stable and has less “moving parts”.

One of those options is a programming language that’s even older than C by a 
year. It’s Pascal. Yes, Pascal has a large ecosystem, but the compiler itself is 
small, and the language is stable.

And the FreePascal community treats FreeBSD as a first class citizen. I, 
however, have seen many issues with the Rust ecosystem when working on FreeBSD. 
I’m sure these issues will be fixed in the future, but for now, the community 
thinks that there are only three Operating Systems on the planet.

And that’s just one option. Another one is Modula-2/Modula-3. It was part of 
FreeBSD two decades ago, and it is still a very stable and a robust language. 
There is even development happening to modernize their toolchain, but I don’t 
think that we need that. We can indeed use it “as is”.

Finally, there’s the last child of Niklaus Wirth, the Oberon programming 
language, which solves 99% of all C problems.

There’s a compiler named “Vishap Oberon Compiler / voc”. I made sure that FreeBSD 
is a first class citizen there about 8 years ago and we’ve been using it on 
production for 5 years now.

One issue with Oberon (and its marketing) is that it relies on a “Garbage 
Collector”, which is not that nice for a low-level system programming language. 
However, I learned lately that the GC can be fine-tuned to make it hardcoded 
during compile time instead of runtime.

My team is also willing to write a PoC of simple FreeBSD programs in Oberon as 
a proof that it works. I already have a PoC of a kernel module in Oberon that 
compiles on FreeBSD using voc.

My point is: yes, we do need better languages. Yes, we do need memory-safety 
and better tooling. But is Rust the answer?

Don’t want to sound like “bragging” but the Rust ecosystem is very new 
while us, Wirthians, have been doing memory-safe programming since 
the 80s.

My personal problem with Rust is that the compiler is unstable (new keywords, 
deprecated keywords, but this can be solved, like you said, with version 
pinning) and that, oh my god, the language is now massive. I like C because I 
*don’t* like C++, because I don’t want to learn for 2 years before using on 
Production. With Pascal, Modula and Oberon, I can just read a single paper, and 
start using the language.

I’m sure there are other options as well. such as Ada. I’m sure there’s more.

If we’re gonna do the work to import a new language into FreeBSD to solve C’s 
problems, let’s have a look at all the options, not just the ones that have the 
budget for marketing. If we chose something based on marketing, we wouldn’t 
choose FreeBSD in the first place, am I right? ;)

I hope this gives a better direction for the future.

Kind regards,


—
Antranig Vartanian
https://antranigv.am/
PGP Key ID: 0x2D59F21C

> On 5 Sep 2024, at 10:09 PM, Alan Somers <asomers@freebsd.org> wrote:
> 
> By now I expect that most of you have seen the long list of new
> security advisories that just came out.  Strikingly, all were the
> result of memory handling errors.  And none of them wouldn't have
> happened if their respective programs had been written in a
> memory-safe language.
> 
> In fact, of all the C bug fixes that I've been involved with (as
> either author or reviewer) since May, about three quarters could've
> been avoided just by using a better language.
> 
> The real takeaway here is that C is no longer sufficient for writing
> high quality code in the 2020s.  Everyone needs to adapt their tools.
> Programmers who don't will increasingly come to resemble experimental
> archaeologists, i.e. people who learn flintknapping to "keep the
> knowledge alive".  Such people are valuable, but definitely niche.  I
> for one don't want my career to go in that trajectory.
> 
> To summarize, here's the list of this week's security advisories, and
> also some other recent C bug fixes of my own involvement:
> 
> Buffer overflow
> ===============
> https://cgit.freebsd.org/src/commit/?id=3aaaca1b51ad844ef9e9b3d945217ab3dd189bae
> CVE-2024-45288 FreeBSD-SA-24:09.libnv
> https://cgit.freebsd.org/src/commit/?id=a06fc21e770a482c8915411ebc98c870e42dd29b
> CVE-2024-41928 FreeBSD-SA-24:10.bhyve
> https://cgit.freebsd.org/src/commit/?id=af438acbfde3d25dbdc82b2b3d72380f0191e9d9
> CVE-2024-42416 FreeBSD-SA-24:11.ctl
> https://cgit.freebsd.org/src/commit/?id=db87c98168b1605f067d283fa36a710369c3849d
> FreeBSD-SA-24:11.ctl
> https://cgit.freebsd.org/src/commit/?id=5c9308a4130858598c76f3ae6e3e3dfb41ccfe68
> CVE-2024-32668 FreeBSD-SA-24:12.bhyve
> 
> Integer overflow
> ================
> https://cgit.freebsd.org/src/commit/?id=36fa90dbde0060aacb5677d0b113ee168e839071
> CVE-2024-45287 FreeBSD-SA-24:09.libnv
> https://cgit.freebsd.org/src/commit/?id=c3e6dfe55c0e81d0717b0458bc95128384c3ebe8
> FreeBSD-SA-24:14.umtx
> 
> Use after free
> ==============
> https://cgit.freebsd.org/src/commit/?id=670b582db6cb827a8760df942ed8af0020a0b4d0
> CVE-2024-45063 FreeBSD-SA-24:11.ctl
> https://cgit.freebsd.org/src/commit/?id=62f40433ab47ad4a9694a22a0313d57661502ca1
> CVE-2024-43102 FreeBSD-SA-24:14.umtx
> 
> Uninitialized memory access
> ===========================
> https://cgit.freebsd.org/src/commit/?id=ea44766b78d639d3a89afd5302ec6feffaade813
> CVE-2024-8178 FreeBSD-SA-24:11.ctl
> https://cgit.freebsd.org/src/commit/?id=0f2b2276abc305905e7d88619a7abca26b0dd7eb
> 
> Memory Leaks
> ============
> https://cgit.freebsd.org/src/commit/?id=2909ddd17cb4d750852dc04128e584f93f8c5058
> 
> Incorrect union member access
> =============================
> https://cgit.freebsd.org/src/commit/?id=9a5a7c90d5e5971fe2b9c9265e9279a6f173a8f3
> CVE-2024-6119 FreeBSD-SA-24:13.openssl
> 
> Concurrent unsychronized memory access
> ======================================
> https://cgit.freebsd.org/src/commit/?id=1f5bf91a85e93afa17bc9c03fe7fade0852da046
> 
> RAII
> ====
> https://cgit.freebsd.org/src/commit/?id=4b3141f5d5373989598f9447ab5a9f87e2d1c9fb
> 
> Unchecked errors [^1]
> ======================
> https://cgit.freebsd.org/src/commit/?id=35f4984343229545881a324a00cdbb3980d675ce
> https://cgit.freebsd.org/src/commit/?id=eced2e2f1e56b54753702da52a88fccbe73b3dcb
> https://cgit.freebsd.org/src/commit/?id=f625d038d2ae59fa1ae81b76079da464ed6db61a
> 
> Not preventable by a safer programming language
> ===============================================
> https://cgit.freebsd.org/src/commit/?id=7d6932d20aedbbb220cd78e90ab4e82d1abaad31
> https://cgit.freebsd.org/src/commit/?id=6efba04df3f8c77b9b12f1df3e5124a7249b82fc
> https://cgit.freebsd.org/src/commit/?id=4b72bab96e8978eaed30fd44f7f51e1b4918d4db
> https://cgit.freebsd.org/src/commit/?id=b64afa41d56e98b5817aaf14c7deb0fa7e2142fb
> 
> [^1]: while not memory-safety bugs, Rust's lints actually make
> ignoring errors like this pretty difficult.  So I consider these bugs
> to have been preventable.
>