The ISRG wants to make the Linux kernel memory-safe with Rust
The Internet Security Research Group (ISRG)—parent organization of the better-known Let's Encrypt project—has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis.
As we covered in March, Rust is a low-level programming language offering most of the flexibility and performance of C—the language used for kernels in Unix and Unix-like operating systems since the 1970s—in a safer way.
Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts—not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly.
Using Rust for new code in the kernel—which might mean new hardware drivers or even replacement of GNU Coreutils—potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows—significant sources of performance and security issues in complex C-language code.
Previously: Linus Torvalds: Don't Hide Rust in Linux Kernel; Death to AVX-512
Related: Microkernel, Rust-Programmed Redox OS's Devs Slam Linux, Unix, GPL
Following Layoffs, Mozilla and Core Rust Developers Are Forming a Rust Foundation
Related Stories
There's a new operating system that wants to do away with the old mistakes and cruft in other operating systems. It's called Redox OS and is available on GitHub. It's aimed at creating an alternative OS that is able to run almost all Linux executables with only minimal modifications. It features a pure ecosystem using the Rust programming language which they hope will improve correctness and security over other OSes. They are not afraid to prioritize correctness over compatibility. The philosophy being that "Redox isn't afraid of dropping the bad parts of POSIX while preserving modest Linux API compatibility."
Redox levels harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, the Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
Redox OS seems to be supported on the i386 and x86_64 platforms. The aims are microkernel design, implementation in Rust language, optional GUI — Orbital, newlib for C programs, MIT license, drivers in userspace, common Unix commands included, and plans for ZFS.
They want to do away with syscalls that stay around forever and drivers for hardware that, for a long time, simply isn't possible to buy any more. They also provide a codebase that doesn't require you to navigate around 25 million lines of code like Linux.
Perhaps the mathematically proven L4 microkernel is something to consider over the monolithic kernel approach where any single driver can wreck the system? One aspect to look out for is if they map the graphic cards into user space.
Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel
Kernel developers appear to be eager to debate the merits of potentially allowing Rust code within the Linux kernel. Linus Torvalds himself has made some initial remarks on the topic ahead of the Linux Plumbers 2020 conference where the matter will be discussed at length.
[...] Linus Torvalds chimed in though with his own opinion on the matter. Linus commented that he would like it to be effectively enabled by default to ensure there is widespread testing and not any isolated usage where developers then may do "crazy" things. He isn't calling for Rust to be a requirement for the kernel but rather if the Rust compiler is detected on the system, Kconfig would enable the Rust support and go ahead in building any hypothetical Rust kernel code in order to see it's properly built at least.
Linus Torvalds Wishes Intel's AVX-512 A Painful Death
According to a mailing list post spotted by Phoronix, Linux creator Linus Torvalds has shared his strong views on the AVX-512 instruction set. The discussion arose as a result of recent news that Intel's upcoming Alder Lake processors reportedly lack support for AVX-512.
Torvalds' advice to Intel is to focus on things that matter instead of wasting resources on new instruction sets, like AVX-512, that he feels aren't beneficial outside the HPC market.
Related: Rust 1.0 Finally Released!
Results of Rust Survey 2016
AVX-512: A "Hidden Gem"?
Linus Torvalds Rejects "Beyond Stupid" Intel Security Patch From Amazon Web Services
Rust Core Team + Mozilla To Create A Rust Foundation
Rust's core team and Mozilla are announcing plans to create a Rust foundation with the hopes of establishing this legal entity by year's end. The trademarks and related assets of Rust, Cargo, and Crates.io will belong to this foundation. Work is well underway on establishing this foundation with originally coming to the idea of possibly creating an independent Rust foundation last year, now pushed along by the recent Mozilla layoffs and the global pandemic. This should allow the Rust community more safety rather than being reliant upon a sole organization (Mozilla) and help foster growth and open up new possibilities.
Lay(off)ing the foundation for Rust's future
Previously: Mozilla Lays Off 250, Including Entire Threat Management Team
Related: Linus Torvalds: Don't Hide Rust in Linux Kernel; Death to AVX-512
(Score: 4, Funny) by Anonymous Coward on Tuesday June 22 2021, @10:03PM (12 children)
The problem with these millennial languages is that their proponents are easily distracted by the next exciting new language and then there's no one to support them. Meanwhile, C++ has been chugging along with only minor changes since the late 1800s.
(Score: 0) by Anonymous Coward on Tuesday June 22 2021, @10:11PM (9 children)
Anyone who's resistant to change has no place in IT.
(Score: 0) by Anonymous Coward on Tuesday June 22 2021, @10:21PM (7 children)
Change your gender, or else.
(Score: 0) by Anonymous Coward on Tuesday June 22 2021, @10:31PM (4 children)
They already have, and you now asking them to change it back is tantamount to violence.
(Score: 1, Funny) by Anonymous Coward on Tuesday June 22 2021, @11:29PM (3 children)
Holy Jesus Fucky McFuckface - there are 1024 (and counting) genders to choose from! He can do a new gender every day for 2.8 years, and never have to repeat.
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @12:01AM (2 children)
Isn't that a plan for when Potato Gender [thepostmillennial.com] stops working?
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @12:15AM (1 child)
If a tater masturbated on zoom, how would you know?
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @02:20AM
Mayo on the keyboard.
(Score: 0) by Anonymous Coward on Tuesday June 22 2021, @10:32PM
(Score: 4, Interesting) by shortscreen on Wednesday June 23 2021, @12:42AM
gender changes -> medical industry profits
software changes -> IT industry profits
You see? There is a difference.
(Score: -1, Spam) by Anonymous Coward on Tuesday June 22 2021, @10:32PM
The words of a punk who unironically believes that "only the Sith believe in absolutes" thought-terminating garbage quote -- and who also believes that a developer who has a good point and defends that good point is toxic and meritocratic, while a bunch of purple-haired Jewish* trannies arguing about pronouns all day while China and corporate America are slipping bugs by them left and right is totally acceptable for an OS with more than its share of annoying security braggarts. Linux is a perfect example of how Judeo-Globalism can destroy good societies in only the span of a few years.
* It's totally fine for Jewish developers to be rude, annoying, racist, and otherwise pointlessly discriminatory though!
(Score: 2) by Tork on Tuesday June 22 2021, @10:34PM
Heh. I can't tell if this is clever satire of another Slashdotter came wandering in over here. Funny either way, tho.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 5, Interesting) by dltaylor on Wednesday June 23 2021, @04:15AM
I've worked on embedded stuff, UNIX and Microsoft kernels and drivers and application low-level utilities and libraries over the course of decades of programming.
My only difficulty with C++ is that I've only ever met less than a handful of programmers that actually know how to write in that language. At best, there is always half the performance and 2 to 4 times the amount of run-time code as "C". Just the simplest feature of base and derived classes seems to be beyond them. I have seen multiple instances of empty base classes and the "derived classes" made by "copy, paste, and tweak" from the first working instance. Wrapping as many as 8 layers of classes over just about every byte of data memory is common, too. That's the part of Rust that gives me pause: micromanaging references. Good as modern CPUs may be, winding down some daisy-chain of references is a performance hit. Yes, Virginia, there are layers of references in the Linux kernel, but type-unsafe as it may be (is, probably), I've seen the compilers streamline the object code.
Perhaps I'll rewrite one of the drivers I worked on in Rust and see how for myself if I'm avoiding a pitfall no longer present.
(Score: 0) by Anonymous Coward on Tuesday June 22 2021, @11:32PM
this looks like an intrepid carrion eater post to me
(Score: 4, Insightful) by fakefuck39 on Tuesday June 22 2021, @11:38PM (7 children)
>Memory-Safe with Rust
>offering most of the flexibility and performance of C
A car can go 0-60 in 6 seconds. That car can tow a 3000lb trailer. Article: A car can go 0-60 while towing a trailer.
No Shelock, Rust does not have the performance of C when you use in a memory-safe way. It does however have the option to use it unsafely, to get the performance of C.
(Score: 0, Troll) by Anonymous Coward on Wednesday June 23 2021, @12:09AM
So then Yterniti Schlubmann the tranny kernel hacker rewrites a kernel module in Rust and every fucking block in that code is unsafe.
The "improvement" is reinventing the wheel in a more verbose and ugly version of C owned by the fine Judeo-globalists at Mozilla, with none of the time-tested proving of existing kernel code. "Unsafe blocks, eh?" Might as well code in C fucking sharp.
Shit languages like Rust and Objective C, like the later episodes of the Star Wars franchise, only get pushed on people because a bunch of Jews decided they should be. The public has already decided that all three of those suck ass, but then critics are accused of racism while Google and Twitter wind back the like counts of said critics.
(Score: 2, Interesting) by Anonymous Coward on Wednesday June 23 2021, @04:56AM (5 children)
So slow. [debian.net]
Rust can be just as fast as, if not faster than, C when used in a memory-safe way. It all come down to the algorithms used by the programmer in the abstract machine and optimizations the compiler used for the target architecture. Of course Rust blocks of a category of low-level algorithms in the abstract machine, but that doesn't mean a different, just-as-fast method cannot exist. It also isn't uncommon for the high-level algorithm to be optimized into the faster result in either language. Just like everything else in life, the answer to "which language is faster" is "it depends."
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @08:55AM (3 children)
That's hardly a fair comparison. Look at the source code for reverse-complement, for example. C version is mostly idiomatic with lots of comments. Rust version is using hand-coded specialized instructions while being twice as long as the C version.
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @09:37AM (2 children)
And? Nothing is stopping C from doing that too. And the safe ones are hardly considered slow. As I said, a lot more goes into "speed" than just the language.
(Score: 4, Insightful) by maxwell demon on Wednesday June 23 2021, @01:32PM (1 child)
The point of course being that C doesn't need to do that in order to be fast.
To make a car analogy of your conversation:
“A Porsche is faster than a VW Beetle.”
“Look, my VW Beetle is going as fast as a Porsche.”
“But that's because you added a rocket engine to your Beetle.”
“You can do that with a Porsche, too.”
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Wednesday June 23 2021, @10:54PM
Apparently it does since the C versions are all slower, some by an order of magnitude. You should also note that all versions of the reverse complement Rust programs are faster than the C versions whether or not they use "special instructions" or safe-only code. But just keep focusing on the languages used instead of keeping the actual nuance in mind.
(Score: 2) by fakefuck39 on Thursday June 24 2021, @12:09AM
you're comparing two completely different programs that accomplish the same goal in completely different ways, and going "see, if I write bad c code and compare it to good rust code, they're the same speed."
you are correct in your claim, and that's all i gotta say about that.
(Score: 1, Funny) by Anonymous Coward on Tuesday June 22 2021, @11:41PM (2 children)
Is Rust just a Microsoft joke then?
(Score: 2, Touché) by Anonymous Coward on Wednesday June 23 2021, @03:28AM
It will be when it's integrated into the Linux kernel
(Score: 3, Interesting) by crafoo on Wednesday June 23 2021, @11:07AM
It's a containment language for people deemed to dangerous to write in C. In that regard, it has probably made published C code more memory safe, on average.
(Score: 2) by DeVilla on Saturday June 26 2021, @09:52PM
Rust isn't a bad language. Being able to stay compatible with the C ABI while providing higher level features and better memory safety ain't bad. It's performance isn't broken in any way that it can't improve in time has C has been able to over the years.
The big thing that make it inappropriate for the kernel and any important infrastructure code right now is that it can't target enough architectures. Once the compiler front end for GCC is stable and assuming it remains well maintained, that stops being a problem. There are other possible fixes such as adding more targets to llvm or getting the entire world to agree to deprecate any platform llvm doesn't support, But there are roads forward here.
There is also the risk that rust will start retro-fitting more features in as other languages have been unable to resist doing. C seems to avoid doing that by defining itself as a language that would add any high level features. Things only seem to creep in after all the compilers have manage to add it. Usually back porting extensions from C++, but sometimes not as with member initialization. Rust seems to like to stay in "active development". It will be hard for them to resist.