Rust in the FreeBSD kernel

T-Aoki said:
Even if doing so, things like "run Linux on Bhyve", "run Linux on emulators/something" and "porting Linux apps to FreeBSD" would remain here. 😅
Click to expand...
As long as there is a FreeBSD/bhyve/linux emulation connection, that is fine and in fact should have a place other than off-topic! But may be discussing the finer points of systemd and other such linux specific stuff can go in a linux forum!
 
Sorry for the Linux excursion. It was Rust triggered and I went WTF on the social aspect of that message.

To get back on the Rust topic, I wonder how the different Rust toolchains for kernel and apt will be managed.
 
bakul said:
But may be discussing the finer points of systemd and other such linux specific stuff can go in a linux forum!
Click to expand...
Just an idea (not sure possible / meaningful enough or not), but "Implement BSD-licensed systemd emulator to be startup from rc.d scripts" could be a candidate for kinda GSoC to ease porting interesting new softwares?

If implemented in /bin/sh and parts of helpers in C, base would be the place for it. But if implemented in something NOT in base, ports would be the place for it (except codes for tests like /usr/src/tests and /usr/tools/test only).

If Rust becomes official part of LLVM project itself, and defaulting cdylib (which Rust guys would hate) as its object linking style, Rust in base would be far more realistic than now. I feel it unlikely, though.
 
T-Aoki said:
There seem to be FUDs (i.e., by US gov.) that all projects SHALL switch to memory-safe languages.
Click to expand...
This is what the DoD says: https://media.defense.gov/2025/Jun/...RABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF

Excerpt:
The goal of these documents is to strengthen national cybersecurity by reducing memory-related vulnerabilities, which requires more than developer discipline and best practices. Achieving better memory safety demands language-level protections, library support, robust tooling, and developer training. While decades of experience with nonMSLs have shown that secure coding standards and analysis tools can mitigate many risks, they cannot fully eliminate memory safety vulnerabilities inherent to these languages as effectively as the safeguards used in MSL.
...
MSLs such as Ada, C#, Delphi/Object Pascal, Go,Java, Python, Ruby, Rust, and Swift offer built-in protections against memory safety issues, making them a strategic choice for developing more secure software.
Click to expand...

So not just Rust and not really FUD + it is a guide/recommendation for (presumably govt controlled) critical infrastructure software, not "all projects" as you say. AFAIK this is still being discussed and not a requirement to sell your software to the govt entities. Quoting more:
Conclusion
Memory vulnerabilities pose serious risks to national security and critical infrastructure. MSLs offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability. Adopting MSLs can accelerate modern software development and enhance security by eliminating these vulnerabilities at their root.
Click to expand...

The report is worth reading, especially the "open questions and study areas" section.

While their goal is admirable, it is just not realistic to rewrite everything in memory safe languages. Nor is memory safety sufficient.
 
You must log in or register to reply here.
Back
Top