Re: The Case for Rust (in any system)

On Fri, Sep 06, 2024 at 09:19:44AM UTC, Baptiste Daroussin wrote:
> On Thu 05 Sep 12:09, 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.
> > 
> > To summarize, here's the list of this week's security advisories, and
> > also some other recent C bug fixes of my own involvement:
> > 
> 
> Jumping on this one, I think at least that is my understanding from the previous
> threads, that using some rust has not been rejected, so keeping discussing
> at length and trying to force convince people will not lead to anything that
> would make progress on the rust integration process.
> 
> On the other side there have been many "work to do, problem to solve" that has
> been raised to allow to make it happen, so far I have seen none of the rust
> people actually trying to work on solving those issues, I would have expected
> now to see patches, design proposals, questions and so on to move forward.
> 
> For the people who want to see rust usage in base, it is time to start the
> actual hard part if you don't want those threads to be seen as "yakafokon" (as
> we say in french, I don't know if there is an equivalent of it):
> - make a plan
> - write patch and poc on how to integrate to our build system
> - discuss with the people who volunteered to help on the build system, on the
>   release engineering, or on the packaging side.
> - create AND lead the working group to make this happen.

Hey Baptiste et al,

I'm including the email I sent to this list last week below.
Unfortunately, due to having to clean up some fraudulent financial
activity last weekend, I didn't make any progress. I'm hoping to split
my time this weekend between working towards my OSCP cert and this
work.

==== BEGIN ORIGINAL EMAIL ====
So, to those thoughts, in list form (in no particular order):

1. Use of Rust compiler toolchain support will be for userland
   components in an opt-in fashion. Meaning, all userland components
   written in Rust will be optional.
2. It does not make sense to perform a vendor import of the Rust
   compiler toolchain and standard libraries. All Rust code in the src
   tree must be built from an external toolchain.
3. I believe the notion of an external toolchain could be abstracted
   such that we can support any optional userland component written in
   a language supported by that external toolchain. This would imply
   that other alternative languages could be supported with minimal
   work (Zig, TypeScript, Python, Java, etc.)
4. We could provide auto-detection mechanisms for determining which
   external toolchains are available, their language support, etc. The
   initial proof-of-concept would likely be limited to Rust to save on
   time and complexity.
5. As the work matures, and perhaps as a requisite for eventual
   inclusion, we could land support for more than Rust. This might be
   a step too far, but hey, it's one of the thoughts I had.
6. So all of this wrapped up means that:
   A. This is NOT a call to rewrite everything in Rust. This work will
      only permit NEW, OPTIONAL components to be written.
   B. Other languages/toolchains/ecosystems could be supported, not
      just Rust.
   C. Initial focus is on userland components. Rust in the kernel is
      out of scope for this initial proof-of-concept.
   D. I would like to see Rust in the kernel. That would be a good
      next area of focus once userland support reaches some level of
      maturity.

My first goal will be to get a better understanding of
src.git/Makefile and src.git/Makefile.inc1. As I study that, I'll also
study your work, Alan. I really appreciate the time you have taken. I
might reach out to you and Warner directly for further questions.
==== END ORIGINAL EMAIL ====

I feel like I should elaborate on item 6.A a little bit. It would be
cool to see some utilities rewritten in Rust (bhyve would be a great
candidate), but my work will focus only on new (completely optional)
utilities solely to get some momentum going.

I should also note that this likely will expand FreeBSD's existing
notion of an external compiler toolchain. If I understand correctly,
though, the existing external toolchain support targets C/C++ code.
I'd like to expand that to support !(C || C++), beginning with Rust.

So, for the community reading between the lines, I'm hoping to make
this support languages/ecosystems other than Rust. That includes
Ada/SPARK, Python, Java, or even Brainfuck for the true masochists.
;-)

I'm starting with Rust, though, because that's what appeals most to
me. Hopefully, as time progresses, others can expand that work even
further for those additional languages/ecosystems.

${LIFE} does tend to be a bit chaotic and unpredictable at the moment,
so I can't promise timeframes--which is why I usually use the word
"hope" when talking about what I would like to accomplish within a
given weekend/month/etc.

Let's see how this goes. :-)

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc