Rust Takes 'Tentative First Step' Toward Linux Kernel (thenewstack.io) 120
In his This Week in Programming column, Mike Melanson writes:
Rustaceans' dreams of Rust's inclusion in the Linux kernel are one tiny, ever so slight step closer to becoming a reality, with this week's "intentionally bare-bones" inclusion in Linux-next, the development branch of the Linux kernel... Curb your enthusiasm, however, as this remains a rather tentative first step of many necessary steps before Rust fully lands in the Linux kernel.
A rather brief post on LWN.net summarizes where we are rather succinctly:
Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language.
Indeed, Miguel Ojeda, a software developer and maintainer of the Rust for Linux project writes that the proposed inclusion "does not mean we will make it into mainline, of course, but it is a nice step to make things as smooth as possible," with some changes expected before any decision as to Rust's inclusion are made.
For those of you less familiar with Rust, part of the appeal here comes with Rust's memory safety features, especially in comparison to C, which the Linux kernel is currently coded in. Part of the problem, however, is that Rust is compiled based on LLVM, as opposed to GCC, and subsequently supports fewer architectures. This is a problem we've seen play out recently, as the Python cryptography library has replaced some old C code with Rust, leading to a situation where certain architectures will not be supported. Presently, the proposal to include Rust in the Linux kernel limits this issue by saying that Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."
A rather brief post on LWN.net summarizes where we are rather succinctly:
Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language.
Indeed, Miguel Ojeda, a software developer and maintainer of the Rust for Linux project writes that the proposed inclusion "does not mean we will make it into mainline, of course, but it is a nice step to make things as smooth as possible," with some changes expected before any decision as to Rust's inclusion are made.
For those of you less familiar with Rust, part of the appeal here comes with Rust's memory safety features, especially in comparison to C, which the Linux kernel is currently coded in. Part of the problem, however, is that Rust is compiled based on LLVM, as opposed to GCC, and subsequently supports fewer architectures. This is a problem we've seen play out recently, as the Python cryptography library has replaced some old C code with Rust, leading to a situation where certain architectures will not be supported. Presently, the proposal to include Rust in the Linux kernel limits this issue by saying that Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."
Tainting the kernel (Score:4, Funny)
I that what is called "tainting" the kernel?
Re: (Score:1)
"blessing" is the proper term
Re: (Score:1, Troll)
Re: (Score:2)
Rust is the new SystemD (Score:2, Informative)
Re: Rust is the new SystemD (Score:2)
Re: Rust is the new SystemD (Score:5, Insightful)
The Rust language itself isnt that large of a problem, its more the implementation. The compiler / toolchain is a royal fucking pain in the ass to bootstrap. There is only one "rust", unlike C, which is a true language with multiple implementations. Rust is a full blown, in-housed ecosystem that is very complicated to move to new platforms. While there is complaints about legacy platforms not being supported, there is also issues with moving forward too. There have been countless issues with Rust compiler on ARM, and I can only imagine it getting worse as we move to other targets like RISC-V and beyond. Its "great" if you're already in the supported ecosystem (Intel CPUs), but anything else has been an absolute nightmare to support.
Re: (Score:2)
Well, that is a ton of exceptionally good reasons to not allow it in. I guess this will just be another meaningless stunt by the fans of a language that is not worth much at this time.
Re: Rust is the new SystemD (Score:5, Informative)
Re: (Score:1)
Re: (Score:2)
Just like wireguard as well. I remember a few years back on the dd-wrt forums shills from the wireguard community trying to cram that shit down the throats of dd-wrt and get it into the kernel there before they got it in the mainline kernel. Now those folks are trying to ram it down the throats of *BSD. Thankfully *BSD has pushed back calling the code experimental at best.
I am quite prepared to rewrite my software, currently in C, to use Rust. Its the best Lint facility that currently exists to help insure flawless code, particularly if you use malloc and free in complex environments. If you do not use dynamic memory (alloc / free), then C is great as is, for development.
Re: (Score:2)
I can understand lauding the Rust linter, but slamming malloc / free? I *like* being in full control of memory allocation / deallocation, heck, I even use alloca in some places. There is nothing wrong with malloc / calloc / realloc or whatever flavor of heap allocation you prefer. Sure memory alignment can be a bit of a pain, but even Rust defers to alloc for that. People like to complain about C, but C does exactly what you write, nothing more If you blow off your foot, it's because you loaded the gun, aim
Re: (Score:3)
Looks like it. yes. Basically the people that know what they are doing are not seeing any of the claimed advantages of Rust. Hence they have to resort to "stunts" like this one. I will certainly never build parts of a kernel that are in Rust.
Re: Rust is the new SystemD (Score:2)
Re: (Score:2)
Re: (Score:2)
Pretty much all languages have been defined by their implementations at one time or another. Haskell used to have multiple implementations, but GHC became dominant. Languages that had a hard standard (like Scheme or ML) and multiple implementations, either never really went anywhere, or the bits that went anywhere left the standards behind (Ocaml for ML, Racket for Scheme).
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered
Re: (Score:1)
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered over - as the GCC vs. LLVM issues mentioned in this post illustrate.
It easier to sell an idea that obsoletes on old one. The reality? LLVM implementations must/need to talk to GCC implementations...
Re: (Score:2)
There is a reason why good old C has been used for over 50 years.
And the reason is that somebody has to provide job security for all the security hackers with hats of various colors.
"Derp! But all the security problems are from stoopid mistakes! They wouldn't be there if all the C coders had top 1% skill level!!!"
Math fail.
Re:Rust is the new SystemD (Score:5, Insightful)
"Derp! But all the security problems are from stoopid mistakes! They wouldn't be there if all the C coders had top 1% skill level!!!"
The string mistakes wouldn't be there if programmers used a better string library in C. This doesn't require top 1% skill level.
The memory mistakes wouldn't be there if programmers used a better memory library in C. This also doesn't require a top 1% skill level.
It doesn't require a genius to avoid buffer overflows in C, it takes general competence. Although maybe most programmers these days don't have general competence.
Re: (Score:3)
Re: (Score:2)
That's well and good, and if I was forced to use C ever again, I'd use it if possible. (It still doesn't help with bounds checking, NULL dereferencing and other issues, though.)
However, much of the time people claim that one reason they're using C is because they can't tolerate the unpredictable pause times associated with GC.
Re: (Score:3)
"Since C lacks any kind of automatic resource management" - Here you go: https://www.hboehm.info/gc/ [hboehm.info]
Please, please, ask Linus to include the Boehm garbage collector as an underpinning of the Linux kernel. I just want to read his response :)
Re:Rust is the new SystemD (Score:4, Informative)
Since C lacks any kind of automatic resource management, any "better library" still requires manual steps to do lifetime management. They do not solve the fundamental problem.
You are changing the topic. You were talking about security problems in C, and I gave you the solution. Then you changed the topic to resource management.
I think your problem is that you don't like C, which is fine, but it's not a problem for the rest of us.
Re: (Score:2)
Resource management IS security management in C. Haven't you ever heard of a dangling pointer?
You're not as much as a C wizard as you think you are.
Re: (Score:2)
You're not as much as a C wizard as you think you are.
I'm not a C wizard, I just know how to use libraries. If you have trouble with that, you must be really, really bad.
Re: (Score:2)
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
Since you think they can, not only are you not a C wizard, but you're also dangerously incompetent. You should be restricted to coding in Java at the very most.
Re:Rust is the new SystemD (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
*Everyone* needs a language with "training wheels". Every single human being on this planet make mistakes.
Even if you use C, it is irresponsible to release a program of any importance without having at least run it through "training wheels" like Coverity and valgrind.
Some people are just too arrogant to realize this. That's one reason this world is saddled with such shitty computer security.
Re: (Score:2)
C is the language for people who value lines of code.
Personally I prefer a language where I can automate the tooling, so I don't have to keep manually doing all the tedious, repetitive parts.
Re: (Score:2)
I can't believe how this got score 5,Insightful as it is so wrong.
By such definition, there are no competent programmers. All of us do mistakes once in a while. So, when some says that programmers need to be "competent" to program in C, they are talking about some fictitious nonexistent people. Following this thinking, you might be "competent" one minute and totally "incompetent" the next one.
I think overconfidence is a big evil and responsible for big part of software issues. Show me a "competent" programm
Re: (Score:2)
Re: (Score:2)
As for competency, C is a simple language. If you understand how CPUs function and how C code is turned into machine code there's not a lot of mystery there. I've be doing this stuff professionally for over 30 years, I'm pretty aware of the available pitfalls and footguns that C provide
Re: (Score:2)
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
And I gave you a way to deal with buffer overflows, and apparently you ignored it. Thus I can safely say that you're a troll, not someone who wants to learn.
Re: (Score:2)
Man, are you dense.
For the fifth time, your purported solution IS NOT SUFFICIENT TO DEAL WITH BUFFER OVERFLOWS.
Re: (Score:2)
And I gave you a way to deal with buffer overflows, and apparently you ignored it.
Did you? You just said to use a library. Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
I find it hard to believe, in the Stack Overflow/Github era, that there are people out there still wrangling their own strings if there's a commonly accepted "best" library for this kind of stuff. We still see tons of exploits of this nature.
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows, wit
Re: (Score:2)
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows,
ok, well it works for Java, so you need to think a little more to convince yourself. (Before you say something like, "Java has memory protection" think a little bit, because even without the memory protection, the Java string library API offers no chance to have a buffer overflow).
Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
Probably because most programmers are as crappy as you. Seriously, why don't you think a little bit before posting?
Re: (Score:2)
For the fifth time, your purported solution IS NOT SUFFICIENT TO DEAL WITH BUFFER OVERFLOWS.
It is. There is an easy way to tell that I'm right here: the content of your post has devolved into yelling. You have no logical argument left.
Re: (Score:2)
all you had to do was put a link to some library that provided any form of evidence for your claim, but you just thought you'd attack me instead - colour me surprised that someone with an attitude of "every other programmer is bad except for me" only resorts to personal attacks
(won't read any further comments from you on the issue)
Re: (Score:1)
But there's much more than that. The C specification as a whole is a vast minefield of gotchas and undefined behavior, well beyond just buffer management. It takes many years of experience to even be aware of most of them. How do people acquire such experience?
If you don't go out of your way to disable compiler warnings, you become aware of them the moment you attempt to compile code that would result in that behavior.
But no one is denying C has problems.
We are pointing out that your solution, replace C code written to the C specification with Rust code written to the Rust specification, isn't a solution at all.
No Rust specification exists.
If you want us to change languages, you need to make sure your destination language at least exists, and at best exists and i
Re:Rust is the new SystemD (Score:4, Insightful)
Since C lacks any kind of automatic resource management,
Here is a hint: In an OS kernel that is exactly how you need it to be. Applications are a different matter.
Re: (Score:2)
void foo(int N, double (*a)[N])
{
(a*)[N] = 1;
Conditional features in C (Score:2)
I do not think that C lacks bound checking. It simple does not require it. It is your C implementation which may lack bounds checking.
Since C11, the international standard for the C programming language has defined a few conditional features, such as variable-length arrays (VLAs) [wikipedia.org]. Implementations need not implement such features, but if they do, they must implement them with the specified syntax and the specified semantics. It sounds like you're making out array bounds checking to be such a conditional feature. So what's the syntax to enable it?
Re: (Score:2)
No, it is not an optional feature of the standard and it does not require new syntax. But a bounds violation is undefined behavior which simply means that the standard does not define semantics for it. So any compiler is free to add bounds checking. In the example above, GCC and clang will detect the out of bounds check at run-time when using certain compiler flags, .e.g. -fsanitize=undefined will cause the program to give a run-time instead of executing a out-of-bounds access. This works for both VLAs a
Re: (Score:2)
Now there's an idea. Do systemd in Rust.
Once you get that working, come back and we'll give you another piece to play with.
Re: (Score:1)
Re: (Score:1)
If you're running Slackware, you're halfway towards being competent enough to run a BSD system. I like Slack, but why not make the leap?
Re: (Score:1)
If you're running Slackware, you're halfway towards being competent enough to run a BSD system. I like Slack, but why not make the leap?
Running BSD to do what? You will have to be more specific.
Re: (Score:2)
In context, I conclude that the following was meant:
If you administer Slackware on a desktop PC or server for a particular purpose, you're halfway towards being competent enough to administer FreeBSD for the same purpose. Why not give FreeBSD a try?
Re: (Score:2)
Cause *BSD are years behind Linux on any metric. And their code quality generally sucks.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Gentoo user here. I compile all of my software from scratch, including the kernel, because Gentoo is a source-based distribution. So this does impact me. Build dependencies tend to be as tricky in my environment as runtime ones.
Having said that, I believe that the beginnings of what will likely be a decades-long effort to replace C and C++ are long overdue.
You need something low-level if you truly must directly manipulate memory or CPU registers or other hardware. Today that is almost always C or C++, b
Re: (Score:1)
One real step needed: (Score:5, Insightful)
Rust needs a formal specification. Having a formal specification ensure that despite any future changes to the language that it will be possible to implement a compiler that can compile the code. A lot of work has been done to move toward standard C code (as well as supporting GNU C extensions in Clang) so adding code that relies on a single compiler with no formal specification would be a step in the wrong direction.
Re: (Score:2)
Re: (Score:1)
It also looks like inviting tool chain bloat to me. So far you need a C compiler to build the kernel, do we really need the extra dependency on a Rust compiler?
Re: (Score:1)
Bloat is the word. I just lost 4 hrs of my life watching rust build under llvm on BSD. All because I wanted a new version of Firefox.
This machine is not especially small or slow (4 cores, 64 bits, 8 gigs, 3 GHz...) But it reminds me of trying to compile Open Office on a 486.
Holy shit I miss 20 yrs ago when you could configure *everything* on a RH box in minutes with plain text, some bash and C. (OK, maybe sed and awk)
Programming language in OS kernel? (Score:1)
Is this only Rust, or do we already have other programming languages on the inside of the Linux kernel?
Re: (Score:2)
Re: (Score:2)
So how do you think they write the kernel if they don't use programming languages? The Linux Kernel is written in C but they have now opened up for new device drivers to be also written in Rust.
Why does the kernel need to be "opened up" to accept Rust programs? For the kernel these are just compiled binaries, why does it need to know what language it was written in?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
even if you managed to make Pascal bind to C
Would that not be a task for the linker rather than for the compiler?
And every single attempt to merge Pascal code would be rejected by the kernel maintainers
Of course, but that is a management issue.
(I'm not trying to be obnoxious, these are genuine questions and I appreciate the answer you and others have given.)
Re: (Score:2)
Yes there is nothing stopping you from creating your own home-brew linker and Pascal compilter from achieving this but that is not the question that are being solved, what is being solved is the possibility to create a device driver in Rust and having that same driver being accepted upstream in the Linux kernel proper. This means that #1 the maintainers will accept that code (which they won't do with Pascal since they currently only accept code written in C and soon some new device drivers in Rust) and #2 t
Calling convention (Score:2)
even if you managed to make Pascal bind to C
Would that not be a task for the linker rather than for the compiler?
The compiler still needs to know the calling convention [wikipedia.org], meaning how to set up the stack and the registers when calling a function compiled by another compiler. Only code using compatible calling conventions can be linked together without some routine in the middle that acts as a shim to translate the calling convention. Historically, the popular Pascal compiler for a platform and the popular C compiler for the same platform have used different calling conventions.
Re: (Score:2)
What would stop you is the Pascal ABI is incompatible with C and there's no support in the kernel build system to compile it.
Indeed, in Pascal parameters are pushed on the stack in left-to-right order (and the callee cleans up the stack), while GCC uses right-to-left (and the caller cleans up the stack).
However, GCC supports several languages, perhaps I should have chosen gfortran as an example rather than Pascal (since the GNU Pascal front-end does not seem to be supported anymore).
Re: (Score:3)
Re: (Score:2)
The kernel consists of binaries, why does it matter from which languages these binaries have been generated?
Re: (Score:3)
Because you need a pile of toolchain support if you add stuff built in a different language. Rust requires a pile of runtime support crap, too. It's nowhere near as lightweight as the C standard library.
Re: (Score:1)
Sorry, I misunderstood your question. When you said 'programming language in the kernel' I thought you were a layman who thought it was actually C in the kernel, not machine language.
Now I understand the question to be 'why does it matter from which language these binaries have been generated?' and I'll give my opinion (and it's just an opinion, not a definitive answer).
Mostly it's a question of maintenance and efficiency of the runtime. C is 'close to the metal', and you can have a pretty good idea of
Re: (Score:2)
Rustaceans? (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
What should one call them? Rustics maybe? If somebody writes a combination of C and Rust are they Crustaceans?
Re: (Score:3)
Re: (Score:2)
I wish I had the other Funny mod point for you.
Ah, the Google news makes sense (Score:2)
Rustacean (Score:3, Funny)
Rust's big problem (Score:1)
Re: (Score:1)
Yes, what a tragedy you can't be a racist mysoginistic fay-bashing asshole on their forums.
Re: (Score:1)
The woke people by far are the real racists and misandrists, making scapegoats in denial of their own failings as humans.
Re: (Score:2)
LOL, let me guess, you think the guy carrying around the Confederate flag is just celebrating his "heritage" and the guy with the swastika tattoo is just interested in promoting an open dialog!
You racist shit-bags are something else.
Re: (Score:1)
You call someone racist when they point out femi-nazi hatred of men, and various black leaders and performers spewing white hate. You are something else.
Then you mention two random lowlifes, and make assumptions about how I feel about them as an argument?
You're pathetic and prove my point, you virtue signaling empty set.
Re: (Score:2)
If I were playing right-wing racist shitbag bingo, I'd have a coverall.
Fuck off and die, racist shitbag!
Re: (Score:1)
Look at you spewing hate and accusations of racism like a smokescreen, to cover up your lack of rational thought.
Re: (Score:2)
I really don't care what a racist shit bag thinks about me. The world will be a better place once your kind is eradicated.
Go on, now, fuck off and die like a good shit bag racist.
Re: (Score:1)
you're the one spewing rabid hatred, a typical woke snowflake triggered, can't handle reality.
Re: (Score:2)
If that even vaguely represented most feminists you might have a point. But "Feminazi" is some sort of bizarre assertion made by misogynists basically projecting their own insecurities and biases on to other people.
Re: (Score:1)
Shouldn't we wait (Score:1)
What about GOlang? (Score:1)
Re: (Score:1)
Re: (Score:2)
Golang is trying to be a server language (or infrastructure language, since that's what people are calling servers these days). It does a good job of handling threads, and it has an efficient GC. Golang is trying to replace Java and C++ on the server.
So a database might be written in Golang, but not a kernel.
Re: (Score:1)
I'm a bit paranoid (Score:1)
Ada/SPARK would be a much better choice (Score:1)
Be more specific (Score:2)
Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."
What is that supposed to mean? What criteria are they thinking of applying? If the architecture is suitable to have a unix kernel on it, it might possibly end up interfaced with nearly any sort of hardware. This is a world where modern embedded microcontrollers exist that would easily kick an older desktop's ass. A world where someone made a retro C64 cartridge with an ethernet controller in it.
I've seen examples of the Linux kernel running on everything from a mainframe down to an SD card.
GitHub plot hole (Score:2)
I'll address the parts about GitHub on the basis that obstacles to interaction with the rust-lang organization [github.com] are on-topic.
There's one part of your post that confuses me:
When logging into GitHub one day (2019), after discovering that my issues all returned "404 Not found" errors, and after being forced to enter a code sent via e-mail: "Your account has been flagged. Because of that, your profile is hidden from the public."
Probably a false alarm in GitHub's automatic spam detection. Mail GitHub support to find how to proceed. (Source: einpoklum's answer on Stack Exchange [stackexchange.com])
Recently, after Microsoft had bought GitHub, [...] they had locked me out with a message about having sent a "verification code" to the throwaway e-mail address I used when registering, obviously long since abandoned and inaccessible.
Then at what address did you receive "Your account has been flagged"? Sounds like a plot hole.
Apparently, having the right password is no longer enough to prove that you control an account.
You are correct that it isn't because of high-profile, large-scale password database breaches.