Rust in the FreeBSD kernel

[msplsh]

entire computing platform

Yeah, with which nobody can agree on how to manage memory.

That's objectively false.

Looking at these GSP binaries

 

[cracauer@]

Yeah, maybe my memory's faulty, but I thought it was C++. That's still a weird stack Obj-C -> C -> C++.

There also was "Objective-C++", which allowed some early C++ constructs in Objective-C. I forgot when and where that was introduced.

A GUI on NeXTStep would be Objective-C, though.

 

[cracauer@]

So does the V language. Example:

//C function declaration in V
fn C.select(ndfs int, readfds &C.fd_set, writefds &C.fd_set, exceptfds &C.fd_set, timeout &C.timeval) int
....
res := C.select(fd + 1, &read_set, C.NULL, C.NULL, &ts)

That is a foreign function definition written out. Looks like what you would do in Lisp/SBCL.

Not sure where you see the particilarly easy integration of V and C.

 

[bakul]

See my next comment: https://forums.freebsd.org/threads/rust-in-the-freebsd-kernel.99645/post-722551

 

[kpedersen]

There also was "Objective-C++", which allowed some early C++ constructs in Objective-C. I forgot when and where that was introduced.

Out of interest, do you know Apple's rationale back then for choosing C++ for DriverKit and writing specific macOS userspace drivers?

It feels like a strange choice, considering their ecosystem. It looks to be vanilla C++ too (albeit freestanding, without STL), rather than with Obj-C++ extensions.

 

[kpedersen]

See my next comment: https://forums.freebsd.org/threads/rust-in-the-freebsd-kernel.99645/post-722551

Just seen in that same discussion that they will also be "publishing the same demo with Sqlite and Quake translations.".

Quite interesting and I look forward to checking it out. If they are even 90% successful (C++ <-> C isn't 100% either), then that would be quite a strong candidate for getting vlang an inbuilt C parser.

 

[cracauer@]

Out of interest, do you know Apple's rationale back then for choosing C++ for DriverKit and writing specific macOS userspace drivers?

It feels like a strange choice, considering their ecosystem. It looks to be vanilla C++ too (albeit freestanding, without STL), rather than with Obj-C++ extensions.

No idea, sorry.

 

[Beastie7]

And if you are thinking that tagged pointers do not require any C code to be rewritten you are likely going to be disappointed.

My point is that the cost of compartmentalizing an existing C/C++ codebase (or parts of it) in capability mode is far less economically taxing than rewriting swaths of drivers/applications in a completely foreign (and arguably unnecessary) language. Some changes even consisting of only several to a few hundred lines of code for relatively big codebases (examples are all over the web). If memory safety was such a concern to that crowd; they'd better off placing those concerns lower in the stack (ie. CHERI). But anywho, I side with FreeBSD kernel dev objections.

 

[bakul]

My point is that the cost of compartmentalizing an existing C/C++ codebase (or parts of it) in capability mode is far less economically taxing than rewriting swaths of drivers/applications in a completely foreign (and arguably unnecessary) language.

They are not comparable. Using capabilities is like wearing seatbelts -- to protect you against unforeseen "runtime" events. Using a better language is like strictly following best practices in a factory to build a safer car. Just explaining the difference, not arguing for Rust in kernel.

IMHO a better strategy might be to consider making C a stricter language and extending it with borrow checking/ownership protocol, liveness tracking etc. This may take years but will allow stepwise/incremental improvements and will be less disruptive than adding Rust code (and/or make that easier *once* C has equivalent features and programmers get comfortable with them). Notice that over the years C has become somewhat stricter and compilers have grown more options to control some of this.

 

[LibreQuest]

I thought the title said "Rust in peace".

 

[msplsh]

Out of interest, do you know Apple's rationale back then for choosing C++ for DriverKit and writing specific macOS userspace drivers?

It feels like a strange choice, considering their ecosystem. It looks to be vanilla C++ too (albeit freestanding, without STL), rather than with Obj-C++ extensions.

Probably because other people write drivers in C++.

System Extensions and DriverKit - WWDC19 - Videos - Apple Developer

One of the next steps in modernizing and improving the security and reliability of macOS is to provide a better architecture for kernel...

developer-rno.apple.com

 

[cracauer@]

Just for completeness, here is C++ for FreeBSD kernel modules (comparable to this Rust proof of concept):

libcpp.ko

C++ runtime for FreeBSD Kernel

gitea.nerdland.org

 

[cracauer@]

Here is a CVE in a Rust library that can lead to remote code execution. To make things worse, the official crates contain several forks of the library with the error, at least one popular one of which is unmaintained since 2023 and doesn't have the fix.

Meet tarmageddon

TARmageddon Flaw in Async-Tar Rust Library Could Enable Remote Code Execution

High-severity TARmageddon flaw (CVE-2025-62518) in Rust’s async-tar libraries enables RCE via header parsing bug.

thehackernews.com

 

[Beastie7]

muh security

 

[T-Aoki]

Here is a CVE in a Rust library that can lead to remote code execution. To make things worse, the official crates contain several forks of the library with the error, at least one popular one of which is unmaintained since 2023 and doesn't have the fix.

Meet tarmageddon

TARmageddon Flaw in Async-Tar Rust Library Could Enable Remote Code Execution

High-severity TARmageddon flaw (CVE-2025-62518) in Rust’s async-tar libraries enables RCE via header parsing bug.

thehackernews.com

This would indicate that Rust is NOT safe for every aspects.
Memory safety is NOT all of the vulnerabilities.

And also means crate is BAD. It should be maintained (approval by Rust dev authoritatitives on adding / modifying should be forced).

 

[cracauer@]

And also means crate is BAD. It should be maintained (approval by Rust dev authoritatitives on adding / modifying should be forced).

It is an interesting question whether you should kick out libraries that are unmaintained and known vulnerable.

Doing the kickout would make all projects using the library (even as an indirect dependency) fail to compile.

 

[T-Aoki]

It is an interesting question whether you should kick out libraries that are unmaintained and known vulnerable.

Doing the kickout would make all projects using the library (even as an indirect dependency) fail to compile.

If Rust does NOT state it is for (memory) safety, I wouldn't have said as such.

So I'm not complaining about FreeBSD ports.

 

[kpedersen]

npm highlights if a dep is vulnerable or unmaintained. But its so common that people ignore it and pull crap in regardless. I imagine crates.io will be in a similar situation once it matures.

But as mentioned earlier, dependencies do regularly become unmaintained over time. Best practice is to reduce dependencies (rather than crates.io encouraging them) and certainly reduce reliance on bindings (which Rust needs to achieve more than text file IO). The whole ecosystem basically works against good quality engineering.

 

[T-Aoki]

npm highlights if a dep is vulnerable or unmaintained. But its so common that people ignore it and pull crap in regardless. I imagine crates.io will be a similar thing once it matures.

What's making things worse is that many "non-professional nor non-enthusiast" users would be thinking "Rust is safe for every vulnerabilities!", even though Rust guys states "memory safe" only.

So crates should be managed by Rust devs to be safe, or Rust devs stop stating about safety.

But the first step should be dropping UNSAFE block and reintroduce it (or its successor) only for defining interfaces against other memory-unsafe languages like C and asm, to make "actial" codes written in Rust to be assured "memory safe" by prohibiting to write memory unsafe codes. It should mean Rust to be Turing-incomplete, though.

 

[kpedersen]

What's making things worse is that many "non-professional nor non-enthusiast" users would be thinking "Rust is safe for every vulnerabilities!", even though Rust guys states "memory safe" only.

Indeed, much of the Rust community really have no idea what they are talking about. They just repeat the words of their favorite youtuber. However, those in the Rust community who are experienced and knowledgeable have always been very clear about Rust's key focus being memory safety. Unfortunately, this often does get lost through all the noise though.

So crates should be managed by Rust devs to be safe, or Rust devs stop stating about safety.

This is a hard one. Maybe there are four approaches:

1. Provide a fat standard library (i.e Java) that is developed with more testing guarantees in place
2. Keep to a small standard library (i.e C, C++) but delegate less portable stuff to i.e POSIX and implemented by the OS (again, this will be fairly well engineered)
3. Micro-dependencies (i.e JS/NPM) and just accept that it will be a house on sand
4. A few well known pseudo-standard fat libraries / frameworks (i.e Boost) which has some guarantees but covers a lot of functionality

I find #2 to be the best but Rust is way too small for that and getting buy-in and proper standardization is beyond the abilities of the industry in 2025 unfortunately. Maybe for Rust a compromise between #3 and #4.

But the first step should be dropping UNSAFE block and reintroduce it (or its successor) only for defining interfaces against other memory-unsafe languages like C and asm, to make "actial" codes written in Rust to be assured "memory safe" by prohibiting to write memory unsafe codes. It should mean Rust to be Turing-incomplete, though.

I think I see what you mean. Or at least perhaps just more education as to how an unsafe block can pose more of a risk throughout the codebase than what is simply between the bracers.

 

[Beastie7]

There's something to be said about all of these language package managers; doesn't make sense to me. I'd wager there'd be less incentive for these should the Linux community have uniformity on the matter.

Long Live C and Ports.

 

[msplsh]

Nothing makes ports more or less special than npm or crates when it comes to deciding who to trust.

 

[cracauer@]

Nothing makes ports more or less special than npm or crates when it comes to deciding who to trust.

I don't think that is true. Ports has a pretty limited set of committers. Most original authors of the software in question do not have a commit bid and need another set of eyes on changes. Often you have three people: author, maintainer and committer.

It is my understanding that npm usually allows the author to make changes (updates) on their own.

 

[Beastie7]

Nothing makes ports more or less special than npm or crates when it comes to deciding who to trust.

It's inherently better than any other option. Because the ports framework is being managed by those providing an operating system. Who knows the intricacies of a platform software runs on better than the ones developing it. There's less risk involved trusting them.

"Ports" is also a framework, not just a collection of software.

 

[T-Aoki]

It is my understanding that npm usually allows the author to make changes (updates) on their own.

It's what I fear, which usually does NOT applicable with FreeBSD ports.
If Rust crates are the same, Rust ports in FreeBSD should make each crate into independent ports, like RubyGEMS.