Re: The Case for Rust (in any system)

On Thu, Sep 05, 2024 at 12:09:18PM -0600, Alan Somers 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.

I broadly agree and think that as a project we need to be willing to
take some risks to move our development towards more modern solutions.
Part of that likely means bringing kernel and userspace componants built
in Rust[0] knowing there will be some integration bumps along the way
and understanding that Rust may or may not stand the test of time to the
degree C has (meaning burden or feature loss down the road).  We need to
move forward and all paths involve some risk[1].

While bugs you can't write because the language doesn't let you are the
best bugs, we should also be looking at deterministic ways to improve
our C and C++ memory safety.  In my biased opinion, our most realistic
option for making major advances here is the adoption of CHERI[2].
We've got Arm's Morello prototype today and we expect commercially
available RISC-V silicon in the next year or so.  At this point I hope
to merge CHERI support from CheriBSD[3] in time for FreeBSD 16 (subject to
standardization timelines, funding, and hardware availability).  In the
meantime, we should be looking at orthoginal techniques such as enabling
default initialization of stack allocations.

While the current state of affairs is quite problematic, we do have time.
Regulators are aware of product lifetimes and realistic timeframes.  We
can afford to be methodical and not chase every trend, but I don't think
we can afford to stand still.

-- Brooks

[0] Other languages might well make some sense, but I'd argue that we
should not generally be adding languages that don't have clearly growing
developer communities so some languages mentioned elsewhere are obvious
nonstarters.

[1] This includes the choice to continue as is.  In particular,
regulatory risk is hard to predict.

[2] https://cheri-cpu.org

[3] https://www.cheribsd.org