Why Google is Funding Linux Kernel Development in Rust (msn.com) 80
"Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones," reports CNET:
If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet. Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort.
Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages...
Google credits the Linux community programmers who began the Rust for Linux project. "The community had already done and continues to do great work toward adding Rust support to the Linux kernel build system," Google said in a blog post...
[Rust] has been the most loved programming language for five years running in Stack Overflow's annual developer survey. "Rust represents the best alternative to C and C++ currently available," Microsoft's security team concluded in 2019. The team said Rust would have prevented memory problems at fault in 70% of its significant security issues. And because Rust's checks happen while software is being built, the safety doesn't come at the expense of performance when the software is running.
The goal of the Linux on Rust project isn't to replace all of Linux's C code but rather to improve selective and new parts.
Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages...
Google credits the Linux community programmers who began the Rust for Linux project. "The community had already done and continues to do great work toward adding Rust support to the Linux kernel build system," Google said in a blog post...
[Rust] has been the most loved programming language for five years running in Stack Overflow's annual developer survey. "Rust represents the best alternative to C and C++ currently available," Microsoft's security team concluded in 2019. The team said Rust would have prevented memory problems at fault in 70% of its significant security issues. And because Rust's checks happen while software is being built, the safety doesn't come at the expense of performance when the software is running.
The goal of the Linux on Rust project isn't to replace all of Linux's C code but rather to improve selective and new parts.
That's it (Score:2, Insightful)
I was indifferent to the effort before, but if Google is pushing for it I'm now against it and on the side of the conspiracy theorists.
why? (Score:2)
Re:why? (Score:5, Insightful)
A hard to fix compiler and constantly evolving language is not universally accepted as a good trade-off for fixing kernel memory bugs.
Re: (Score:2, Interesting)
Exactly this. Google is going to be following the old Microsoft strategy of "embrace, extend, extinguish." And the developers taking Google's money are making a deal with the devil.
Re:That's it (Score:5, Funny)
You missed the step with the underpants gnomes. It makes about as much sense.
Re: (Score:2, Insightful)
Don't worry - as usual, Google will get bored of it in a year or so and shut it down.
Welcome newbie. (Score:2)
I'm now against it and on the side of the conspiracy theorists.
Glad to see you're ready to fight the good fight. If you don't have a snorkel and metal bat then buy them. If your all teeth aren't crowned with gold, go to the dentist. And remember, shave all of your exposed skin so that they can't get to you. This is a fight we can win, though I hope you like the smell of rotisserie chicken because this is going to get ugly.
Re: (Score:2)
He's doomed because you forgot to tell him to fill his bathtub with macaroni and to tape a filter-tip cigarette on top of each of the doorjambs in his house.
Re: (Score:2)
Oh please, the filter-tip cigarette thing again? It's a myth I tell you! Also, it doesn't have to be macaroni, any pasta will do.
Re: (Score:2)
Oh please, the filter-tip cigarette thing again? It's a myth I tell you! Also, it doesn't have to be macaroni, any pasta will do.
But only macaroni has that little curve that deflects the 5G mind-control rays. That's science, Gravis.
Re: (Score:2)
But only macaroni has that little curve that deflects the 5G mind-control rays. That's science, Gravis.
Seriously?! Why do you think you get your teeth crowned with gold?! The beta resonance field generated from the interaction of gold crowns and 5G waves is exactly what negates the 5G. The pasta is merely for dispersing radio field probes so that they don't find your home! If you don't have your teeth crowned or aren't wearing a macaroni necklace AT ALL TIMES then you are a liability. Don't risk it, get your teeth crowned with gold!
Re: (Score:2)
Not to worry- I had all my teeth pulled just to be safe. Take that, 5G overlords!!1! For 6G they're going to remove my testes and replace them with chromium-infused cotton balls.
We'll probably see this on Facebook in a week being touted as proof of something or other...or as the "Tik-Tok Pull All Your Teeth Challenge".
Re: (Score:3, Insightful)
I was indifferent to the effort before, but if Google is pushing for it I'm now against it and on the side of the conspiracy theorists.
Insightful? Really? Mods, you drunk or what?
How about you grow up and discuss the topic based on merits, technical pros and cons ... you know, useful aspects?
Re: (Score:2)
Yup, just like the way we do Microsoft, or that other [slashdot.org] discussion.
Re: (Score:2)
Back when assemblers were hard to come by, I wrote original programs for DOS via "copy con: program.com " then alt-numpad codes... built up the practice from the old hex code listings in paper magazines.
Installed a keylogger on a high school admin machine with locked up disk drives/ports and only the screen and keyboard accessible.
vale GCC (Score:4, Insightful)
As long as Rust is optional, you only need a C compiler.
But if it's mandatory, a dependency is introduced on LLVM.
Not saying that's necessarily a bad thing but we don't need a situation where kernel.org keeps the core of Linux C-only and Google has a permanent downstream fork with unmergeable code that relies on rust.
Re: vale GCC (Score:4, Insightful)
Re: (Score:1)
Is it possible to cross-compile Rust code to C++ and then compile that for whatever architecture you like? I thought Rust was basically just C++ with strict typing and safer memory management?
Re: (Score:1)
Re: (Score:2)
For most of its history, the Linux kernel had a dependency on the gcc C compiler. In fact, when I started compiling my own kernels, the dependency was on a particular version of gcc - 2.95.2 as I remember. I'm not sure why you think having a dependency on a particular build tool is a problem as long as that tool is open source.
Re: (Score:2)
Because that particular tool cannot generate code for all of the architectures that the Linux Kernel currently runs on.
To make that problem go away, expand LLVM's coverage.
mixed languages (Score:4, Insightful)
this is a really bad idea. the decision has been made: tens of thousands of contributors all contribute to the linux kernel in one language: c. caveat, of course, some of it is in assembler.
with contributions in a second language, now any programmer wishing to contribute to the linux kernel is now forced to learn two programming languages:
1) c
2) rust
for that reason alone, it *does not matter how good rust is*, this is an extremely bad idea.
all developers must now learn: ... ...
1) secure programming techniques in rust
2) secure programming techniques in c
3) best kernel practices in rust
4) best kernel practices in c
5)
6)
you get the idea.
not only that, but rust is a moving target, and, worse, a moving target that (a) depends on LLVM daily builds and (b) relies on a distribution system that is not properly linked to a web-of-trust.
c compilers are stable, distributed by either GPG-signed tarball or through a Distro that has at least some level of responsibility to check the source code has not been compromised, where rust uses its own distribution mechanism which has not been properly security-vetted and relies exclusively on HTTPS. we've already seen problems with nodejs (npm), with archlinux developers de-registering usernames and hackers picking up their account and re-registering a package and inserting trojens into archlinux: "cargo" is no different, being based on exactly the same principle.
some of these things are fixable in the medium term, but in the long-term they are not. if google had announced that they were forking the linux kernel entirely, or if google had announced that they were developing an entirely new kernel product, there would not be a problem.
Re:mixed languages (Score:4, Insightful)
> all developers must now learn:
> 2) secure programming techniques in c
Too bad they didn't. 30 years on and there are c-semantics bugs. It won't be better 30 years from now either.
It really doesn't matter what modules are written in as long as they stick to the API.
Some of this was discussed on the previous two dupes of this story, but at least this one has a good title.
Re: (Score:2)
"de-registering usernames and hackers picking up their account"
that's its own fucking problem.
Why the hell would that be allowed? use a server generated UUID or something else cryptographically secure.
Re: (Score:3)
That is not it's own problem; it is the exact same problem rust has. A lack of web-of-trust based distribution chain. We know that leads to security issues, and that is why rust not having that is a problem.
And indeed, it should not be allowed. But it is. And letting that into the kernel is a Bad Idea (tm).
Re:mixed languages (Score:4, Insightful)
all developers must now learn:
Developers have to learn new things ANYWAY. At least with Rust, it removes some really common avenues of error, so the actual mental burden is reduce.
best kernel practices in rust
Did people miss Linus' and other kernel developer thoughts on the matter? Mostly everyone is in agreement that Rust won't be used in the core for a long while. It is best suited for writing drivers. So new drivers written in Rust will be in Rust, and only those developers wanting to maintain them will learn Rust. Everyone else who is working on the core C stuff will still use C.
Try doing some background reading instead of going on an ill informed rant.
c compilers are stable, distributed by either GPG-signed tarball or through a Distro that has at least some level of responsibility to check the source code has not been compromised, where rust uses its own distribution mechanism
What? The main source is on Github. It uses git. The source code is just as likely to have been compromised as any GPG-signed tarball... What are you even trying to say here?
"cargo" is no different, being based on exactly the same principle.
Why would the kernel Rust code use cargo? Even without special some kernel policy, the way to kernel is developed practically requires all dependencies to be maintained in the kernel repo itself. No one, not even the Rust kernel developers, would go to the trouble of trying to keep the versions of the kernel code and external cargo versions in sync.
Not a conspiracy theory, but... (Score:2)
Good or bad, Google has a profit roadmap for doing this.
This will end up like everything else in IT work (Score:3, Interesting)
In reality, unless Linux blesses it it's going nowhere. Didn't he kind of recently say that he was skeptical of using Rust in the kernel?
Personally, I can't wait for the first Day Zero attack on Rust where something they overlooked is actually an exploitable security nightmare and then the language maintainers will have to scramble to fix it ASAP.
Re: (Score:2)
Personally, I can't wait for the first Day Zero attack on Rust where something they overlooked is actually an exploitable security nightmare and then the language maintainers will have to scramble to fix it ASAP.
As opposed to C where they're like "well, that's C, wait 5 years for the next standard if you like but it won't fix any holes". If you're STILL waiting for a zero day in Rust, then it's doing it's job.
Re: (Score:2, Troll)
Yep. They'll combine C and Rust, call it "CRust", and it'll still have more holes than a Chinese whorehouse.
Re: (Score:2)
In reality, unless Linux blesses it it's going nowhere. Didn't he kind of recently say that he was skeptical of using Rust in the kernel?
Not exactly, no.
https://arstechnica.com/gadget... [arstechnica.com]
Related project (Score:3)
Reminds me of this other completely unrelated project by Google [slashdot.org], coincidentally also announced on Thursday.
How big is the "problem"? (Score:2)
Does anyone have a sense of what percentage/number of kernel security and stability bugs are likely to be prevented by using Rust?
It seems, from afar, like Linux kernel code is among the better vetted code around written by good programmers and seems (at least by the time it's blessed) to have few bugs of the sort that Rust is likely to prevent.
Even if my perception is correct, that doesn't mean incorporating Rust is a bad idea, but there is a cost in terms of somewhat complicating the tool chain. Also, if
Re: (Score:1)
Does anyone have a sense of what percentage/number of kernel security and stability bugs are likely to be prevented by using Rust?
After extensive study*, the number I came up with is approximately "0".
.
*I was 'studying' naked pics of porn stars, but still...
We will see... (Score:3)
Slight problem. (Score:2)
There is no formal specification for Rust. Seriously, it cannot be implemented by a third-party because the people who control it may decide to change it's behavior the next day. What that means is that every part written in Rust will be limited to the platforms supported by the official Rust compiler. It also means that if Rust should go the way of the dodo bird that you are SOL.
Re: (Score:2)
There is no formal specification for Rust.
C's formal specification has one huge problem: Whenever there is a difficult issue or corner case (or even an issue that *used* to be difficult 40 years ago), it simply punts and says that's "undefined behavior".
So it's not really much of a specification.
Re: (Score:3)
Alas, the specification prevents any one compiler from changing how the language "should" behave but the same is not true for Rust. If your compiler isn't doing exactly what the Rust compiler does then your compiler is considered to be wrong. Even if your compiler used to match the behavior of the Rust compiler, once they change the behavior in the Rust compiler, your compiler is now broken. You will forever be playing catch up to the Rust compiler because it's the only true implementation of Rust.
Re: (Score:2)
Where's the problem with that?
There is a kind of formal specification. It just happens to be in the form of a couple of hundred thousand lines of code. That's still less ambiguous than any English language text.
Re: (Score:2)
Where's the problem with that?
Because it's a moving target.
Re: (Score:2)
So is any formal specification.
Do you think that it would be appropriate to implement a C compiler today using only the original K&R book?
Re: (Score:2)
False. ANSI C is always still ANSI C. C99 is always still C99. C11 is always C11.
You target a specific version, and generally speaking, not the latest one but one a few back. I mostly use C99 at work.
Years and years between named versions is not comparable to something that can literally change tomorrow.
Re: (Score:2)
Because it's a moving target.
So is any formal specification.
This is inaccurate because a specification is approved a compiler can state it conformed to that standard it and never be wrong. There may be new specifications released but that does not invalidate older specifications which is the difference here. A proper compiler for C89 can always a proper compiler for C89, even in 2021 when the C17 standard exists but if your compiler does not always conform to Rust (even when it changes behavior) then it's no longer correct nor proper.
Re: (Score:2)
Not my problem.
I'd rather that some alternate compiler vendor deal with sorting out some version numbers than use a language that was already lame, dangerous and shoddily defined back in 1989.
Re: (Score:2)
You would love Microsoft's compilers, they don't conform to any standards. ;)
(OK, they recently added support for standards but it's still funny)
Re: (Score:2)
Not my problem.
Of course it's not your problem... but it is a problem for anyone interested in making a Rust compiler. Why do you think there is only one alternative compiler and it sucks?
Re: (Score:3)
Code is not a specification. You couldn't write a new Rust compiler based on inspection of the existing one except by copying it exactly.
Re: (Score:2)
There is no formal specification for Rust.
C's formal specification has one huge problem: Whenever there is a difficult issue or corner case (or even an issue that *used* to be difficult 40 years ago), it simply punts and says that's "undefined behavior".
So it's not really much of a specification.
You missed the part where "undefined behavior" is either things you're not supposed to do in quality code, or things that don't matter how they're implemented as long as it is internally consistent.
Re: (Score:2)
That's the big problem with C: It's essentially humanly impossible to write quality code. Subtle minefields of undefined behavior are one big reason for that.
Re: (Score:2)
That's the big problem with C: It's essentially humanly impossible to write quality code.
That's a moronic statement.
Subtle minefields of undefined behavior are one big reason for that.
No, C isn't Perl where all possible ways are just a matter of opinion. If the behavior is undefined, that means it isn't one of the things you're supposed to be doing.
It is possible for others to live without a nanny, even if you still need one.
Re: (Score:2)
It's not a moronic statement. It's objective reality based on years of experience.
The morons are people like you, way overconfident of their own capabilities. This is how we got to the current situation: a world awash with security vulnerabilities.
Google funds a dupe.. (Score:1)
https://linux.slashdot.org/sto... [slashdot.org]
I bet that 50 years ago (Score:3)
I bet that 50 years ago, people just like you, said that it is wrong to develop an operating system (UNIX) in C , and that operating systems must be written in low-level language. Times are changing, and if Rust can produce code as fast as C, then why the hell not?
I do think that ideally it would be better to add keywords/pragmas/whatever to C that would gradually give it Rust like semantics, but the Rust solution is also better than a bunch of old people shouting "nothing can ever improve, let us stay in our ways forever"
Most loved programming language... (Score:1)
Rust is the most loved language because Rust has not yet reached the mainstream. Once Rust is in the mainstream, such as a new Linux kernel, people will hate it.
Google will use the rewritten Linux kernel in Rust to then have control over the Rust language...add a new feature to Rust, well since its not useful or our experts don't see the need for it, we don't support it and won't use it....a'la Go which is Google's language. Remember Google is using Linux for infrastructure, so this is a self-serving move.
W
Re: (Score:1)
What would be interesting if Google wanted to rewrite Minix in Rust. :)
Intel might be interested in this.
Re: (Score:3)
They're not re-writing the kernel is Rust, they're just making it possible to write kernel modules in Rust.
That is intended basically just for platform-specific drivers. Rust doesn't even run on a lot of platforms supported by Linux.
Re: (Score:2)
Rust will only remain clean and safe until enough users complain that they can
tRust (Score:2)
Do I trust rust ?
Do I trust Google ?
NO
When I see Google paying all their taxes I'll have just a small amount of trust,
when they stop gathering data on most of the people using the internet I'll have a lot more trust.
Trust Rust YES, Trust Google NO (Score:2)
Re: (Score:2)
Good luck with Rust version dependency hell
Re: (Score:2)
Good luck with Rust version dependency hell
I do not think random libraries will be used in the kernel.
Re: (Score:2)
Heh... guaranteed safety.
Every time I hear people praise Rust, I can only hear a voice in my head reminding me there's no silver bullet. There's just too much emotional rhetoric and security theater in that community for me to take it seriously.
C++? (Score:1)
I know Linus doesn't like it C++.
But which problems exactly does Rust solve that couldn't have been solved by modern C++ already for something like 20+ years?
Language vs Library (Score:2)
Re: (Score:2)
Rust Is Already Causing Issues In Gentoo Linux (Score:2)
In Gentoo Linux, Rust has a dependency for the "SSE2" feature in CPUs, that means it can't run on Pentium III CPUs and below.
As more and more Rust-based programs pervade Linux, it makes it more difficult to build it on those older CPUs.