The Linux Kernel's Second Language? Rust Gets Another Step Closer (phoronix.com) 116
"In 2022 we will very likely see the experimental Rust programming language support within the Linux kernel mainlined," writes Phoronix, citing patches sent out Monday "introducing the initial support and infrastructure around handling of Rust within the kernel."
This summer saw the earlier patch series posted for review and discussion around introducing Rust programming language support in the Linux kernel to complement its longstanding C focus. In the months since there has been more progress on enabling Rust for the Linux kernel development, Linus Torvalds is not opposed to it, and others getting onboard with the effort. Rust for the Linux kernel remains of increasing interest to developers over security concerns with Rust affording more memory safety protections, potentially lowering the barrier to contributing to the kernel, and other related benefits....
Miguel Ojeda sent out the "v2" patches for Rust support in the kernel. With these updated packages, the Rust code is now relying on stable Rust releases rather than the beta compiler state previously, new modularization options added, stricter code enforcements, extra Rust compiler diagnostics enabled, new abstractions for in-kernel use, and other low-level code improvements.
Red Hat is also now joining Arm, Google, and Microsoft in voicing their support for Rust code within the Linux kernel.
ZDNet contributing editor Steven J. Vaughan-Nichols also expects the first Rust code in Linux's kernel sometime in 2022: As Ryan Levick, a Microsoft principal cloud developer advocate, explained, "Rust is completely memory safe." Since roughly two-thirds of security issues can be traced back to handling memory badly, this is a major improvement. In addition, "Rust prevents those issues usually without adding any runtime overhead," Levick said.
This summer saw the earlier patch series posted for review and discussion around introducing Rust programming language support in the Linux kernel to complement its longstanding C focus. In the months since there has been more progress on enabling Rust for the Linux kernel development, Linus Torvalds is not opposed to it, and others getting onboard with the effort. Rust for the Linux kernel remains of increasing interest to developers over security concerns with Rust affording more memory safety protections, potentially lowering the barrier to contributing to the kernel, and other related benefits....
Miguel Ojeda sent out the "v2" patches for Rust support in the kernel. With these updated packages, the Rust code is now relying on stable Rust releases rather than the beta compiler state previously, new modularization options added, stricter code enforcements, extra Rust compiler diagnostics enabled, new abstractions for in-kernel use, and other low-level code improvements.
Red Hat is also now joining Arm, Google, and Microsoft in voicing their support for Rust code within the Linux kernel.
ZDNet contributing editor Steven J. Vaughan-Nichols also expects the first Rust code in Linux's kernel sometime in 2022: As Ryan Levick, a Microsoft principal cloud developer advocate, explained, "Rust is completely memory safe." Since roughly two-thirds of security issues can be traced back to handling memory badly, this is a major improvement. In addition, "Rust prevents those issues usually without adding any runtime overhead," Levick said.
Shut it down (Score:5, Funny)
Isn't this the thing that got that camerawoman killed?
Re: Shut it down (Score:3)
Better question: (Score:1, Interesting)
How about rewriting systemd in rust first?
For these kids, "rewriting linux in rust" is the second milestone after "compiler compiles itself". But linux-the-kernel all in rust really only works well on platforms that support rust, which implies supporting all of its dependencies as well.
Which includes LLVM, therefore C++. But also python, because that's what rust its bootstrapping system is built with. And a sack of other dependencies.
I always thought (turbo) C was hopelessly bloated, costing several tens
Re: (Score:2)
They used to boot themselves in FORTH, but that too got replaced with lua
Can anyone elaborate on this?
Re: (Score:2)
The boot loader was written in FORTH the kernel wasn't.
Re: (Score:2)
Ah, thanks, that makes a lot more sense now.
Though it seems to me that Forth would be the obvious choice there. What do you think was the rational for switching to Lua, of all things?
Lua over Forth (Score:1)
Re:Lua over Forth (slightly OT) (Score:3)
This brings back memories:
Back in the 1980ies I had an Atari 1040ST. I started working on a BBS software for my ST because, and that was really a beauty, the Atari ST had a serial port to which you could connect a mode/accoustic coupler but also one parallel port and two(?) midi ports. The parallel port could be programmed to be a serial port and the same for the midi port(s). Thus you could, if you had, connect three(four?) modems to your Atari ST and allow it to have up to three(4?) user logged-in at the
Re: (Score:2)
Lua has been around a hell of a lot longer than Rust and is not really a fad.
Lua was never popular enough to be a fad.
Re: (Score:1)
The thing about fads is it all depends on who you ask. Jeans are a fad then, so is FreeBSD....
Re: (Score:3)
(Leading comments removed)
dave@NB520:~/Rust/HelloWorld$ cat hello.rs // Statements here are executed when the compiled binary is called // Print text to the console
fn main() {
println!("Hello World!");
println!("I'm a Rustacean!");
}
dave@NB520:~/Rust/HelloWorld$ rustc hello.rs
dave@NB520:~/Rust/HelloWorld$ ls -l
total 9808
-rwxrwxr-x 1 dave dave 10019648 Nov 13 22:51 hello
-rw-rw-r-- 1 dave dave 609 Jun 19 20:30 hello.rs
dave@NB520:~/Rust/HelloWorld$ .
Re: (Score:2)
I cannot duplicate your claim. Granted my version of rust is a few months old. v1.52.1, 64-bit x86_64. Executable is 358k here. Of course that's still huge. But not 10 MB. No idea why your binary is so big.
Re: (Score:3, Informative)
It's still larger than gcc would build from equivalent C or C++, but that's where you can play with dynamic libraries if you wish.
Or stay on C/C++, whatever works well for you.
Re: (Score:2)
Ok whoever modded this post insightful needs to be summarily sentenced to spend 6 hours in the pillory.
Re: (Score:2)
What about the idiot who said Rust is "completely memory safe," even though you have to turn off the safety features to get the performance needed for use in the kernel?
Re: (Score:2)
Actually you can't turn off all of the safety features in Rust, only a few of them are disabled inside of an unsafe block, and it typically isn't needed in most cases, even for high performance.
Awwww shit! (Score:1)
Something about Rust:
1. Libertarians and fascists will denounce Rust as being "woke" because heaven forbid they name their main git branch "main" instead of "master"
2. Boomers/NIMBYs will denounce Rust because they are afraid of change.
3. Regular people will denounce Rust because people who write Rust code call themselves Rustaceans.
No one will actually criticize Rust based on its technical merits or lack there of mind you. There may be a comment here or there denouncing Rust for lacking a language specific
Re: (Score:1, Insightful)
but 99% of the comments
Let me simplify it then, independent of language. It adds complexity and dependencies. The language itself isn't even relevant, no matter how good (or bad) it is. To solve a problem, you create dozens new ones. And all based on the assumption that people make errors, well, that's for sure, but there's not silver bullet for that, not even this magic language.
You want to keep your build environment as simple and basic as possible. Anything that creates complexities and dependencies will bite your tail sooner
Re: (Score:2)
You can't reduce complexity by introducing complexity.
Seems like it should be obvious, doesn't it? I have no idea why so many programmers outright reject this simple fact.
Re: (Score:3)
I have no idea why so many programmers outright reject this simple fact.
It's just part of NIH Complex.
It's the Not Decided Here variant.
"I would have chosen something different, therefore that choice must be wrong. "
Unfortunately this sort of stupidity is somewhat useful in math, and math is somewhat useful in programming, and the study of math increases interest in programming, since math itself is only useful as an ancillary skill.
So you'll always have a bunch of dumb-fucks who are perfectly decent coders but absolute shit software architects, because they're not mentally fl
Re: (Score:2)
Because... frameworks.
Re: (Score:3)
But the typical Rust build environment is really simple and basic. In fact Rust is the easiest compiled language I know of for starting a new project, and bringing in dependencies involves the least amount of work; literally you just type the name and the version number in cargo.toml, that's it. It's a lot easier than C make files, and unlike even more popular languages like Java, you don't even have to bother with all of the ugly XML bullshit.
Re: (Score:2)
The machinery needed to make adding dependencies to a project look simple to the programmer is quite complex.
For a systems language you need simple machinery rather than lots of deeply complex machinery that makes using it look simple to the programmer. rust has the latter, not the former.
That doesn't make any sense, you may as well argue that we should get rid of compilers for this reason.
Re: (Score:1)
But the typical Rust build environment is really simple and basic. In fact Rust is the easiest compiled language I know of for starting a new project, and bringing in dependencies involves the least amount of work; literally you just type the name and the version number in cargo.toml, that's it. It's a lot easier than C make files, and unlike even more popular languages like Java, you don't even have to bother with all of the ugly XML bullshit.
There are infinite ways a compiled system written with an ISO standard language will interact with a compiled language that does not support such standardization once the new system accommodates the new language. Standardization is meant to reduce problems programmers can introduce into a system. I could be wrong but I believe the two cannot exist in Linux without one dominating the conversation.... And more ISO standards too...*waves flag"standards matter"*
Re: (Score:2)
Luckily, because of portability problems with Rust, and the popularity of Linux in embedded computing, the added complexity can only ever be optional.
It's a big drag on their effort, because getting leaders to force a new language on people is the only way to get people to abandon the existing (working) codebase.
Precisely the opposite. (Get a dictionary) (Score:4, Interesting)
> Libertarians and fascists will denounce Rust as being "woke" because heaven forbid they name their main git branch "main" instead of "master"
Libertarians, by definition, believe you can name your branch whatever you want. You do what you want, they'll do what they want. That's why they are called libertarians - liberty, the freedom to do what you want if it's not directly affecting anyone else.
They may chuckle if you show up insisting that they have to stop using the value zero to represent false.
Fascists, on the other hand, are defined by the belief that they should force others to do what they want. Such as forcing you to change to change all your naming structure because some snowflake is perpetually offended.
No one will actually criticize Rust based on its technical merits or lack there of mind you. There may be a comment here or there denouncing Rust for lacking a language specification, that the generated binaries are too big, or bemoan LLVM, but 99% of the comments will fall into those three points.
While you're right that Rust is missing quite a bit technically, the Rust team has *chosen* to be very loud about certain things. For example, they've chosen to loudly claim that Rust is far superior regarding security. Yes, security professionals like myself will call them out for making false claims that out users are risk. The fact is, Rust has little to no security advantage over MOST languages. Proponents of the language loudly shout that Rust make everything secure because it has - the same features that most languages have. Yeah, we'll call you out for false and misleading claims, that's because Rust proponents chose to make those claims.
Re:Precisely the opposite. (Get a dictionary) (Score:4, Informative)
Re: (Score:2)
You are confusing libertarians and conservatives
So do the "libertarians" and "conservatives" so it's not much of a complaint.
Most kinds (Score:2)
> I bet there are all kinds of people who disagree with you.
Most kinds of people, in their case. :)
Re: (Score:1)
'they name their main git branch "main" instead of "master"'
Seriously ?!
That's pathetic.
Re: Awwww shit! (Score:3)
Master in this context has no slave counterpart. I always presumed it is like a master tape in music production etc. This is the English language almost every word has multiple meanings and anyone not understanding that and changing words with no difficult connotations because they are uneducated ignorant morons gets my goat.
Kernel fork? (Score:1)
Some architectures are too old or limited to even build the rust compiler so rust code won't be included for those parts. But what about code like drivers that overlaps architectures?
Re: (Score:1)
If you have to cross compile it at all you might just as well use C in the first place. Also cross compilers can produce some pretty hideous inefficient code.
Re: Kernel fork? (Score:1)
Thanks for demonstrating you've never used a cross compiler in your life.
Re: (Score:2)
So a system running Linux is now unable to compile it’s own kernel?
Re: (Score:2)
Some architectures are too old or limited to even build the rust compiler so rust code won't be included for those parts.
Have you heard of cross-compilation? Why would any architecture be too old for that?
Cross-compilation isn't the issue, it is that Rust requires LLVM, and LLVM is supported by less platforms than GCC. And any new platform has to get an LLVM port before you can target it.
It seems to be unlikely to be a real-world problem, though, since even most of the old platforms are supported at this point.
I thought kernel code had to be explicit (Score:3, Interesting)
Which is why C is used but C++ isn't. You don't want the compiler adding in its own runtime code when you need to know *exactly* what the processor will be running at any given time particularly if its an RT kernel. How does that philosophy square with rust having a runtime memory safeguarding system?
Re: (Score:3)
But you are right, you cant have a language/compiler chain that reinterprets - even compiler optimization features can be sketchy making time/space tradeoffs behind your back.
Re: (Score:1)
Re: (Score:2)
You can compile entirely without the standard library, just add the #![no_std] macro. That instead leaves you with the core library, which is basically just the bare minimum needed to compile anything at all (other than a few macros, which have no runtime penalties.)
https://doc.rust-lang.org/core... [rust-lang.org]
Re: (Score:1)
Re: (Score:2)
Which abstractions are you referring to then?
Re: (Score:2)
How does that philosophy square with rust having a runtime memory safeguarding system?
It's my understanding that the whole point of rust is to introduce memory safety without introducing any runtime overhead. Is that not right?
Re: (Score:1)
Re: (Score:2)
If you are using raw pointers, why are you even using Rust? I can write systems code in C++ using managed pointers without doing that. And if I do that, I don't have to worry about all the dependency overhead of Rust. So in what way is Rust better than modern C++ for systems programming? The whole point is automatically managed memory without the overhead other languages bring. Seems to me from what Rust programmers say, Rust can't do that (yet).
The kernel seems like a terrible use case for Rust. R
Re: (Score:2)
If you are using raw pointers, why are you even using Rust?
Why not? It's not as if the whole program is written using them, just in cases where you need it.
I don't have to worry about all the dependency overhead of Rust.
What dependency overhead, specifically?
But until Rust drops the questionable Python dependencies
You mean the scripts in the compiler toolchain? You know none of that has any impact on the runtime, right? That's like arguing that C has overhead from a bash dependency because bash scripts are frequently used for the build processes. Totally irrelevant to the language, and even less relevant to any binaries that you've compiled.
(and several other changes)
Like?
I feel like the Rust community in general doesn't really understand what system programmers want.
TBH I think the Linux kernel developer
Re: (Score:2)
Rust is ok, but the safety features have overhead. They're not free. And maybe if you're on a fat PC that the overhad in the kernel is acceptable, but not if you're on a slower cpu, embedded system, dealing with real time, etc.
Rust is fine, but there's a proselytizing community for it and zealots always make me nervous. Whenever someone describes something new with all pros and no cons, then I know they're leaving something out.
Having static analysis built into a language is nice, and it has no overhead,
Re:I thought kernel code had to be explicit (Score:4, Informative)
Rust is ok, but the safety features have overhead. They're not free.
As in runtime overhead? That's incorrect, the safety features are provided at compile time. In fact Rust even goes out of its way to make sure that abstractions have no overhead.
Unless you're talking about things like bounds checking, which are just built into the statements. You can forgo them if you're absolutely certain that they're unnecessary on a given call, i.e. slice::get_unchecked(), but you have to encapsulate it in an unsafe block or else it won't compile. Even if you leave it intact, the overhead is super tiny, and you shouldn't be using unchecked boundaries even in kernel space without a very good reason. Casually pulling values out of memory without bounds checking is where a lot of security vulnerabilities come from. Take heartbleed for example. This is why if you don't use an unsafe block, the compiler can guarantee memory safety at compile time, and doesn't have to at runtime.
This, by the way, is more convenient than C where, by default, bounds checking has to be manually done by the developer instead of just being safe by default.
Re: (Score:2)
Rust is ok, but the safety features have overhead. They're not free.
As in runtime overhead? That's incorrect, the safety features are provided at compile time
Except that you have to turn them off to interact with most C code...
It's not that "you can forgo them if you're absolutely certain that they're unnecessary" it is that you have to forgo them exactly when they would be benefiting you, because the rest of the kernel is written in C and you have to pass references around.
Re:I thought kernel code had to be explicit (Score:4, Insightful)
Rust is ok, but the safety features have overhead. They're not free.
Rust's safety features come from the compiler overseeing what is allowed to happen in normal safe usage of the language. There is virtually no runtime burden, other than what C might have. Everything happens at compile-time.
The cool thing is that this removes a lot of the bookkeeping that has to be done when writing C. It's almost like having a garbage-collected language, but without the overhead of a garbage-collected runtime.
Re: (Score:2)
Except that to do normal kernel stuff you have to get out of the safe mode. You need a pointer to a random place that doesn't seem like memory and which is not initialized for example.
Re: (Score:2)
No you don't get "out" of "safe mode", you just have to mark the relevant bit of code as unsafe, i.e.
let bar = unsafe { foo.get_unchecked(1) };
Even then, unsafe blocks don't disable all of the memory safety features, it only allows you to do the following that you can't normally do:
- Dereference a raw pointer
- Call an unsafe function or method
- Access or modify a mutable static variable
- Implement an unsafe trait
- Access fields of unions
The borrow checker and everything else remains intact, still providing
Re: (Score:1)
Look how many memory errors there are.
Re: (Score:2)
This begs to differ
How? Look at the very top one for example:
they call CStr::from_ptr on a pointer to the string buffer, the string is terminated at the first '\0' byte, which might not be the end of the string
Literally dereferencing a raw pointer.
Look how many memory errors there are.
Actually this isn't that much. You literally searched everything ever written in rust, and all it comes up with is 318. Let that sink in for a moment. Even then, I see several of these that look more like protocol implementation flaws, not memory errors.
Re: (Score:1)
Let that sink in for a moment
Let what sink in? The fact that Rust, being a young language, and constantly promoted as being safe, has already shown it is not? Let this sink in for a moment: Rust is young and has relatively few high-use code being looked at constantly by security researchers. Give it time and you'll get even more. C++ has been around since the late 80s, building on from C in the 70s. Of course you'd expect a lot more.
Lots of these CVEs are double frees, and accessing uninitialized memory. All of which are the same as
Re: (Score:2)
Let what sink in? The fact that Rust, being a young language, and constantly promoted as being safe, has already shown it is not? Let this sink in for a moment: Rust is young and has relatively few high-use code being looked at constantly by security researchers. Give it time and you'll get even more. C++ has been around since the late 80s, building on from C in the 70s. Of course you'd expect a lot more.
Uhh 318 vulnerabilities over 5 years? That's nothing, especially when you consider that the vast majority of these are unrelated to the standard library.
That's right - Rust has a timebomb because it can't even guarantee that the layout of a common network datastructure remains the same. In this instance it is literally worse than C, which cannot have this problem, barring compiler bugs screwing around with the layout (which doesn't happen often, and would affect Rust equally).
Because counting every rust library ever created, even ones that are rarely used, is totally fair when you're just comparing to vanilla C...
There goes all the claims of Rust being magically data race free by design.
It is data race free by design. Even if that bug was in the standard library, that wouldn't change that fact.
Re: (Score:2)
Actually something I just noticed as well, some of these aren't rust bugs at all. In fact, some of these are C bugs:
https://cve.mitre.org/cgi-bin/... [mitre.org]
Re:I thought kernel code had to be explicit (Score:4, Informative)
How does that philosophy square with rust having a runtime memory safeguarding system?
It doesn't, because Rust doesn't even have one. The memory safeguards are guaranteed at compile time, not at runtime. That's what the borrow checker (among other features) are for. Rust's runtime is very similar to the C runtime in terms of scope, size, and performance. Just like C, the only runtime protections in Rust are for things like heap corruption, stack overflow, etc.
Re: I thought kernel code had to be explicit (Score:3)
How does it know at compile time that an array of 100 elements might be indexed for element 101? It cant, so it must have some runtime bounds checking.
Re: I thought kernel code had to be explicit (Score:4, Informative)
That's provided by the function call. Suppose for example that you created a slice with 100 elements, i.e.
let foo = [0u32; 100];
You can call something like this, which checks the bounds at runtime:
let bar = foo.get(101);
But you can't actually do anything with bar until you've told the compiler what happens if that was out of bounds, because the return type is Option instead of just u32. For example:
let bar = bar.unwrap(); // Unwrap says that if it's out of bounds, trigger a panic and exit the program, otherwise return the value
Or if you're absolutely certain that it is within bounds, you can do this instead
let bar = unsafe {
foo.get_unchecked(101)
};
Note that in this case, you're saying to the compiler, "trust me, I know what I'm doing" and no bounds check is performed. As you told it to do, it will retrieve the value at the 101st offset, which in this case is invalid and undefined behavior. Your program probably won't crash here at runtime, but it can lead to things like information disclosure vulnerabilities.
This is actually pretty nice because in other languages without safety guarantees, you have to do the bounds checking manually, which just as in rust, also happens at runtime. Here, conveniently, it's done for you.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
How does it know at compile time that an array of 100 elements might be indexed for element 101? It cant, so it must have some runtime bounds checking.
You're giving it an excess of credit.
It can't, so you have to turn the checking off.
In real Rust code, the normal pattern is, they write it, it works but is too slow, so they try to speed it up, but they have to turn the checks off in order to use faster or less memory-intensive algorithms. And then they have the same bugs that C would have, except the programmers are mostly people who disliked having to think about those bugs, so they're not as proficient or practiced in avoiding them.
Re: (Score:2)
In real Rust code, the normal pattern is, they write it, it works but is too slow, so they try to speed it up, but they have to turn the checks off in order to use faster or less memory-intensive algorithms. And then they have the same bugs that C would have, except the programmers are mostly people who disliked having to think about those bugs, so they're not as proficient or practiced in avoiding them.
This is way overstated. Bounds checking a fat pointer will make your code neither slow nor memory intensive. If you have a problem with slowness, chances are very good that it has nothing to do with that. The same thing is often said about reference counting, which is also overstated.
Re: (Score:2)
Maybe I am being pedantic here, but do you not contradict yourself here?
The memory safeguards are guaranteed at compile time, not at runtime.
the only runtime protections in Rust are for things like heap corruption, stack overflow, etc.
Additionally:
Just like C, the only runtime protections in Rust are for things like heap corruption, stack overflow, etc.
I am not a professional programmer, nor have I attended school for programming, but I have written C programs and I am completely unaware of C having any protections for heap corruption or stack overflow. What mechanisms are providing these protections and how do you invoke them from within the C specification? What year were those specifications added?
Re:I thought kernel code had to be explicit (Score:4, Informative)
Rust's safety features are compile-time, not run-time. In fact this means you can have even less overhead than C. For example, if you have a C function that accepts a pointer it should check that the pointer is valid before using it and fail gracefully if it is not. In Rust you can skip that testing and error handling code inside the function because the code won't even compile if you try to pass a pointer that isn't valid.
Rust is basically like C but more explicit, rather than less.
Re: (Score:2)
Rust is basically like C but more explicit, rather than less.
I treat Rust as "C with templates", which is perhaps what C++ should have been, instead of "C with classes". With generic programming in Rust, and strict type checking, the compiler will reject code that could lead to undefined behaviour. Rust does allow you to write potentially dangerous C-style code, so you are not being prevented from writing what is required by a "nanny" compiler. However, you have to explicitly label such code as "unsafe", so you are much less likely to make mistakes. With C code, you
Re: (Score:2)
For example, if you have a C function that accepts a pointer it should check that the pointer is valid before using it and fail gracefully if it is not.
Which is a load of bullshit, given the sheer number of memory errors in Rust CVEs.
Re: (Score:2)
Rust is basically like C but more explicit, rather than less.
So, have they gotten around to writing a formal spec for Rust, yet?
Re: (Score:2)
That example is also exactly what C++'s references are, though Rust does have other features that have unique value. C++ can also fairly trivially guarantee nearly all of the scenarios that the Rust fanboys are constantly shouting about as if they were actually novel.
The root of the "problem" here is simply Linus's failure to define the (sub)set of C++ features that would be acceptable in the kernel, because he never bothered to learn it himself, but (rightly) complains of how staggeringly incompetent most
Re: (Score:2)
How does that philosophy square with rust having a runtime memory safeguarding system?
Use #![no_std], implement a panic (if you wish to have that or just avoid the ? operator and related things like Option<T> and what not), set your Cargo.toml to panic = abort to remove unwinding, ensure to set C runtime to zero, tell the compiler to not set implied entry point with #![no_main] and extern the method your assembler will be expecting with #[no_mangle] pub extern "C" since most assemblers look for C names. Likely you'll just do pub extern "C" fn _start() -> ! { //your code } as your e
Re:I thought kernel code had to be explicit (Score:4, Insightful)
I thought kernel code had to be explicit, which is why C is used but C++ isn't. You don't want the compiler adding in its own runtime code when you need to know *exactly* what the processor will be running at any given time particularly if its an RT kernel. How does that philosophy square with rust having a runtime memory safeguarding system?
Rust doesn't use a runtime to safeguard memory. Its type system, checked at compile-time, solely makes the guarantee: "the only place in your codebase where memory safety can be violated (e.g. read-after-free, memory-overrun, concurrent access of mutable data, ...) is in the few blocks you explicitly mark as *unsafe*". This is checked at compile-time, which is why it doesn't need any additional runtime layer or checks.
The reality of working with Rust is that about 0.1% of your codebase is unsafe, so when your team does security audits for read-after-free and memory-overrun they need only focus their attention on these few areas -- manually inspecting the areas to verify that each one satisfies the invariants that its signature claims it does. This is naturally a much more tractable audit than having to check the entire codebase. Also, it naturally doesn't say anything (doesn't help nor hinder) the other kinds of application safety, privacy, credentials &c.
Re: (Score:2)
How does that philosophy square with rust having a runtime memory safeguarding system?
Most of Rust's memory safeguarding is enforced at compile time, as distinct from runtime garbage collection. You can implement reference counted pointers, but I have not needed them so far.
Confused by this... (Score:2)
No. Compiled languages don't run (Score:5, Informative)
> Wouldn't having two different languages running the base kernel slow down the system
In a word, no.
You may be thinking of interpreted languages such as Python, Perl, and PHP. With interpreted languages, /usr/bin/perl is running the code, or /usr/bin/python.
With compiled languages, the language doesn't run the code. There is no /usr/bin/rust. There is no /usr/bin/c. C doesn't run code. What runs is x64 machine code. The binary has 0x90 for "wait one cycle" and that's run directly by the CPU. There's no difference between the compare instruction in the binary produced by a C compiler vs a Rust compiler.
C and Rust are just conventions for how a human can tell a compiler to create a program. The actual program that results could be *identical* whether the request was written in C or Rust. (Though it would be a pretty weird C compiler or programmer that produces a program *exactly* the same as what's produced when starting with Rust.)
The runtime effect is that the two parts use different libraries for common functions like string copy. So you'd have two versions of stringcpy() in memory. That would use a few MB of RAM.
Re: (Score:2)
Even between compiled languages, there is still overhead to translate calling conventions when calling a language A function from language B. Fortunately, C is so dominant that many compiled languages either simply use the C convention or, like Rust, allow calling convention to be configured to work like C.
Re: (Score:2)
yeah IF the calling convention is different AND it uses runtime-thunking instead of handling that at compile time.
Re: (Score:2)
Depending on how pedantic you want to get, there aren't two different languages running: there's only machine code that their respective compilers compile code into.
There are two different run-time libraries, but that doesn't make the code slower, just more bloated. But since both memory and disk space are plentiful by comparison to when Linux was
Re: (Score:2)
There are two different run-time libraries, but that doesn't make the code slower, just more bloated.
And actually, since kernel code kind of needs its own runtime anyway (Linux's C code is built with -nostdlib), there's an opportunity to sync the Rust and C parts up on a common runtime.
Re: (Score:2)
Good. (Score:3, Insightful)
Re: (Score:2)
Promise, potential, etc. maybe. But actual substance? Not so much. Rust is not ready for this.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Someone Wants It Bad (Score:5, Insightful)
I don't really have a dog in this fight, but I can see the constants in human behavior. Others here seem to pick this up as a turf invasion. I'm not sure they're wrong, but I don't see the compulsion. What I do see is a language that wants to be big and big now! Stamps feet and kicks dirt. Or maybe that's the projected impression I get from its proponents.
If time is kind to Rust, then it will be worthy. The only way to prove it carefully is to resist hasty high-end "optics" grabbing adoptions until the basics are complete. And yeah, the basic foundations matter. Immature things hate, just hate having to prove themselves over time. They want all that good stuff now and they are worthy and you're no judge of it.
Re: (Score:1)
Re: Someone Wants It Bad (Score:3)
Rust is required and required now. Competent C programmers are far and few between. Google is quietly writing Linux competitor in Go that will not be a free software. Businesses that don't have Google's slush fund search need cheap programmers that can compete in the future.
Is it just competency or fundamental C problems? (Score:2)
Rust is required and required now. Competent C programmers are far and few between. Google is quietly writing Linux competitor in Go that will not be a free software. Businesses that don't have Google's slush fund search need cheap programmers that can compete in the future.
So the difference between having memory errors is solely a function of programmer competence? Maybe because I've worked most of my life in Java and work for a large software company, bugs creep in, even with the best, most-experienced programmers. Just preventing an NPE (NullPointerException) in Java, for example. Competency reduces the occurrence of this, but never eliminates it. One member writes code that is absolutely perfect today and then the contract changes between them after 10 years of updates
I hope there will be a "no Rust" switch (Score:2)
Because I do not want code from half-whits in my kernel.
Re: (Score:1)
Re: (Score:2)
Excellent. Got a reference?
Let's look at Rust CVEs (Score:2)
https://slashdot.org/comments.... [slashdot.org]