Date: Fri, 6 Sep 2024 16:53:01 +0000 From: Shawn Webb <shawn.webb@hardenedbsd.org> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Alan Somers <asomers@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <t3o2utu5eabqrn7fxmrx4qqvefi6rlvnz34gq5agx7d45z5xjo@aqmevakdknc6> In-Reply-To: <szpkic52zi7s5k23kfsbwz5bppghrvl5eiqtc6bsafffvgljhn@fbnrdx4qvwit> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <szpkic52zi7s5k23kfsbwz5bppghrvl5eiqtc6bsafffvgljhn@fbnrdx4qvwit>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmbbM2YACgkQ/y5nonf4
4fpZFBAAmqcOkKJ49CdgSKG6mUHu1N3iIowY5KOcE7921LgzVIK8RkqO33bEr8n/
vgFp4JDxdWksWrRi7Wlo/XLvOXwrLggEkLkcWA2I9no0wXSP3kIOt4IaOCKMP/+Z
vvwf2fGLb0kW2PLacnAhDKvMqKQOjz5DIohHsL1v5K49QAcAUXj8Q8RNfP5siqE7
A6kekZrkPaH7yk8h8HzSs5YVUYoRPSUkBrme67ZcrNw6OhE733tqrqUgz3jxVqHY
Oh9pF6UOKn/EWMZK/YWRo+dRtTtM0s3HtNyOdH62Ijn5efI6Ot2aG7HkxD50w2gS
NB6hGjhcyRNibZXlavhSitlabQ4C0bdPre59pEVHg9W9omS+p3jTkL38xrurPEVA
NxTdU9nFpujx5mh6sIUsXgZao2Vxz5VcrFzrERU/uCTkD+2rAHn/Cx+SV/07pqom
w58PFztzhU9Wj4gzmCAAAW9vb8mRbkr+7gLPFq0npzcfjuSDJEUiQJJN8yjLkMrn
3+VVUBvGJ/yhVGE/vpLvOlVclqsLwAGG0Qu4jBBNwLPRcOj0MpMG+HPO7WIk+3n6
6oPv5JgqwC7jt99mGBiipIqXj1i3ilRNtpLWHDyVQorkyhqDphvwu0OGGS6Wlv0y
xxTXQBwNUHJP0aRvwUHYfADC4JWNl0yxDCrJQoBhTBqbMm5OH+o=
=F3XK
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t3o2utu5eabqrn7fxmrx4qqvefi6rlvnz34gq5agx7d45z5xjo>