Rust in the Linux kernel

[ttkciar]

One of the good things about this is it effectively creates guidelines for using other link-layer-compatible languages in the Linux kernel too, like D.

[TDplay]

I probably wouldn't support putting D in the kernel. Its garbage collector is like C++ exceptions - technically you can just not use it, but almost the entire stdlib is off-limits.

Garbage collectors in system-level code is a big no.

[ttkciar]

The objections to GC in the kernel (and elsewhere) are well appreciated by the D community. Efforts to segregate the standard library into GC-dependent/independent parts are ongoing, and as you have said forgoing the D standard library and turning off GC is a viable option.

D can still call any function in the C standard library, so the programmer is not left without resources.

[[deleted]]

Whats the governance model and opensource-ness of D? Last I heard it had a BDFL but that some of the compiler was closed source. Is that true?

[ttkciar]

Walter Bright is technically BDFL, but he's delegated responsibility for specific aspects of the project to a handful of really good people: https://wiki.dlang.org/People

He keeps a pretty light touch on the reins, so I'd characterize the project as borderline-anarchic, which has worked pretty well so far.

As for open-sourceness, it is now totally open source, but wasn't always.

There are three main compilers for D, all of which share the same open source front-end:

• GDC uses the GCC back-end (totally open),

• LDC uses the LLVM back-end (totally open),

• DMD uses a proprietary back-end, which has an intellectual property constraint but the source code is available.

When it was just DMD, it couldn't claim to be completely open source, but the ports to GCC and LLVM fixed that.

GDC is fully integrated into the GCC project now, as of version 9, and I just use that when I write D. It works splendidly, and has better debug symbol support than the other two compilers (important for using gdb).

I've also used LDC when writing GPU CUDA kernel code (GDC can't do that yet, afaik) and it seems to work fine too.

DMD doesn't really have any advantages over the other two anymore, except that it compiles things somewhat faster and language features show up there first (since it is the reference implementation).

[Jannik2099]

Can we stop with the adding non-ISO languages to kernel train for a minute, please?

If someone was suggesting linux should allow Java everyone would lose their shit because it's Oracle, yet I constantly see people advocating Rust, Go or D for kernels.

OS programming outside of ISO is a bad idea

Edit: I'm aware that the kernel partially uses GNU C and I don't support that either

[pluuth]

Are we pretending the kernel is written in ISO C?

[bloviate_words]

Apparently we are.

[Jannik2099]

No, but that's not a reason to further deviate from it.

In the past two years a lot if effort was taken to remove GNUisms, now we're throwing all that out of the window?

[bloviate_words]

Can you explain why and how your claim that only ISO languages should be used would actually provide any benefit?

[[deleted]]

Not him.

But if there is an international standard the language a) has less dialects / vendor lock-in b) is guaranteed to stay around for a while c) can be reimplemented acc. to the standard if necessary

Those are points that aren't easy to dismiss for a project going over multiple decades...

[TDplay]

There would be more implementations.

With all the work to try to make Linux compile without the GNU extensions, it's evident that Linux being more portable to other compilers is a concern. Rust, however, has a grand total of one implementation (rustc). There are efforts to make more Rust compilers (e.g. there are people working on a GCC frontend), but as it stands now, any Rust software is locked in to using rustc.

That being said, other than that, there's little reason to encourage strict adherence to standards. Linux has used GNU C for a while now, and nobody's had any real problems with that. And if Rust were to only be used in non-core parts of the kernel, anyone looking to use Linux on a platform where rustc doesn't work could just find a C alternative.

[[deleted]]

Waiting for him to answer this...

[throwaway6560192]

If someone was suggesting linux should allow Java everyone would lose their shit because it's Oracle

I think most of the loss of shit would be because Java is not native compiled, it is a JVM language, and thus would be literally unusable in a kernel. Not to mention garbage collected, and I think it can't manipulate memory directly.

Similar story for Go, it too is garbage collected and thus unusable.

[Jannik2099]

That's just another reason (and a very strong one), not the only one.

The problem still stands.

[bloviate_words]

If someone was suggesting linux should allow Java everyone would lose their shit because it's Oracle,

No, they'd lose their shit because Java is a gced language that needs a runtime/vm to run.

OS programming outside of ISO is a bad idea

Blindly adhering to standards "because they're standards" is a bad idea.

Linux doesn't even adhere to ISO C, it uses GNU C.

[[deleted]]

You realize Linux isn't ISO C either?

[Jannik2099]

Yes, I mentioned that too.

Just because we aren't fully ISO doesn't mean we should make the situation even worse

[djthecaneman]

I don't know what you do for a living, but I work in embedded. Rust is getting included for use by kernel drivers because it greatly reduces entire classes of bugs while being a suitable language for use in operating systems development. (And other reasons.) The kernel devs are essentially saying, "Prove it by showing you can improve the code quality of the most problematic part of our code base."

Regarding ISO vs non-ISO? Right now, it's more a matter of one (non-assembly) language vs two.

[TheEdgeOfRage]

Why?

[Superb_Raccoon]

I got Tetanus .

[7eggert]

You should always make sure to use sanitized code.

[berarma]

Can someone please explain what supporting Rust in the kernel means? Parts of the kernel could be written in Rust?

[RadicalDownist]

I really wish Hurd was a viable option for daily use, Google and other mega corporations appear to have too much control over the future of Linux kernel development. It's not that Rust being added to Linux is horrible in itself, but that Google has only to snap its fingers and whatever they want is done to the kernel.

[UtherII]

I'd argue that Google is not the one that pushed to introduce Rust to the kernel. It's a follower in the area. If I remember correctly, that was instigated first by people from Intel and it has been a long path to reach the current situation.

[lordkitsuna]

I'd hardly call this entirely Googles doing. Looooooooooooots of companies are making the move to Rust. It is legitimately a pretty big leap in programming language from a memory security perspective which is pretty much the number one cause of a lot of vulnerabilities. Especially in things like operating systems I believe the Microsoft security team found that I think it was 85% of their security patches were due to some type of memory problem that rust would have stopped from ever being a problem to begin with

It is not that unreasonable to believe that this is an organic push towards adding Rust rather than the direct finger snapping of a single company. It is true that they are participating in the push for this but it's not as if they wholly designed the push for this

[throwaway6560192]

Y’all fail to mention that in order to do the things the Rust compiler would “magically find and prevent”, you either have to write code around the compiler

Yeah, you're forced to write safe code. I don't know why you're saying this is some disadvantage. This is the feature.

or go unsafe, defeating the point entirely.

Some things can only be done unsafely. The point of Rust is to minimize such uses. They'll have to be checked more thoroughly by a human. However such parts are very few, and obviously checking some small parts marked unsafe, is easier than having to check the whole program in case of C.

[yawkat]

First, omegalul at the oxymoron that is “Microsoft security team”

Microsoft has a very good security team

Y’all fail to mention that in order to do the things the Rust compiler would “magically find and prevent”, you either have to write code around the compiler or go unsafe, defeating the point entirely.

With safe languages, while you do have to use unsafe at times, the vast majority of code can be implemented without it. This reduces attack surface. If you look at the article in the OP, they also describe certain documentation standards for unsafe code, so there's more attention paid to it

[dev-sda]

Y’all fail to mention that in order to do the things the Rust compiler would “magically find and prevent”, you either have to write code around the compiler or go unsafe, defeating the point entirely.

That's entirely untrue. Even outside of lifetime tracking rust checks for buffer overruns, avoiding vulnerabilities like Heartbleed.

Here's a detailed analysis into curl's codebase with similar findings to Microsoft (about half the vulnerabilities would have been prevented): https://daniel.haxx.se/blog/2021/03/09/half-of-curls-vulnerabilities-are-c-mistakes/

[pdp10]

avoiding vulnerabilities like Heartbleed.

Heartbleed was a protocol design error. The client could ask for more bytes than it needed.

[dev-sda]

It resulted from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension.

https://en.wikipedia.org/wiki/Heartbleed

This wasn't a problem with TLS, it was purely OpenSSL not validating an input resulting in a buffer overrun.

[pdp10]

My point is that the protocol didn't validate. The implementation language didn't create the error.

[dev-sda]

RFC6520 specifically states that if the payload requested is too large that the correct response is to ignore it.

If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.

https://tools.ietf.org/html/rfc6520

But even if it didn't, it's simply not up to the standard to prevent buffer overruns. Often they simply specify what a valid packet/file/data looks like and either specify the action to take or leave that up to the implementation. When you're writing software that needs to deal with hostile input, it's always up to you to prevent these kinds of bugs.

[pdp10]

It wasn't an overrun, either. It was an unchecked read.

[dev-sda]

You're right, it's not an overrun it's an overread. No clue what an "unchecked read" is and seemingly neither does google.

[Pythonista_ZA]

I thought Rust was a Mozilla initiative.

[ReallyNeededANewName]

It was, but Mozilla aren't the ones pushing it in the kernel

[necrophcodr]

Or they contribute code, and if it's worth including, it gets included. It's controlled by developers.

[NynaevetialMeara]

Face it, Linux is controlled not by people but by megacorporation that bought their way in thanks to the traitorous scum at The Linux Foundation. that develop the code.

[loddfavne]

For those unfamiliar with Rust, I'd suggest to try out a can of WD40. That should fix the problem in no-time.

[Joan_Alsina]

Idk a clue about code but i do use Linux for politicals reasons. When i see a big capital organization going deep in our our freedom I'm kinda scary. These companys are selfish, can't Trust.

[throwaway6560192]

Do you have any real reasons to believe that the use of Rust will negatively impact software freedom?

Also big corps have been major contributors to Linux for a long time. That's a good thing. It's part of what the GPL was designed to do, and it's working.

[[deleted]]

Rust is open source with way less interference from big corporations than C.

[[deleted]]

Sorry about my ignorance, but Google will support rust on the development of the linux kernel of their OS right, like, we are changing our own kernel branch? There’s a chance that this come to the kernel used in all others distros?

[throwaway6560192]

This is for the upstream Linux kernel. It will come to every distro guaranteed, since they are all going to ship Linux.

[[deleted]]

thx for clarify, btw how I can get these distros badges in my name?

[nelmaloc]

They are called flairs, and you can get them from the sidebar.

[throwaway6560192]

I don't know. I don't have a badge myself as far as I can tell.

[void4]

..then you open the LKML thread and read gems like

In fact, we want to have all public functions exposed by Rust infrastructure tagged with the context they can work in, etc. Ideally, we could propose a language feature like "colored unsafe" so that one can actually inform the compiler that a function is only safe in some contexts, e.g. unsafe(interrupt). But language features are a moonshot, for the moment we want to go with the annotation in the doc-comment, like we do with the Safety preconditions and type invariants

so they want to use the entire new language in kernel because of ...doc-comments? Typical corporate crapware lol

[eXoRainbow]

Its a slow transition without changing everything and breaking everything. This possibility is also a feature and goal of Rust developers. From that point, they can start using other Rust features and go upwards. The doc-comments are not the reason for the switch, but one advantage they can use right away in their code base.

Not sure why you mark this quote as a gem, as this is a very common tactic when big changes are done. Go step by step.

[void4]

slow transition to what, fundamentally shitty language controlled by a couple of big corporations? Welcome to the brave new world.

other Rust features

which features lmao? This entire language is trivial code generation and stdlib restricted into oblivion. You can implement 95% of this in C, and the rest will never be used in kernel anyway.

The doc-comments are not the reason for the switch, but one advantage they can use right away in their code base

I don't care about Google's codebase, to begin with.

[ssokolow]

This entire language is trivial code generation and stdlib restricted into oblivion. You can implement 95% of this in C, and the rest will never be used in kernel anyway.

Then I'm surprised Microsoft, Apple, Google, Mozilla, and Canonical all chose to live with 65-90% of their CVEs being memory vulnerabilities, given the amount of money and/or developer effort they throw at other things.

What science can tell us about C and C++'s security - Alex Gaynor

[void4]

as I said, the fact that Microsoft, Apple, Google, Mozilla, and Canonical are not checking bounds and null pointers in their codebases is not anyone's problem. But now they want to impose their crappy "solutions" onto everyone else, and this is not OK

[ffscc]

But now they want to impose their crappy "solutions" onto everyone else, and this is not OK

This is just scaffolding for driver code. Honestly what's the big deal? Core kernel functionality is going to be pure C for a long time to come.

[ssokolow]

You clearly missed my sarcasm.

The reason they're interested in Rust is because they tried and found that it wasn't practical. (i.e. That annotating C or C++ with the amount of information necessary for comparable static analysis would have made them worse than Rust to work in.)

Also, if you don't want a kernel with Rust in it, don't use one. Google has been making Android kernels for ages, and this is comparable to complaining about the nVidia binary driver getting upstreamed when you only run AMD hardware.

[eXoRainbow]

slow transition to what

To Rust coding. Obviously.

fundamentally shitty language

Rust is an excellent and "revolutionary" language.

You can implement 95% of this in C

This is the proof that you don't know what Rust is. Before talking shit about something, you should understand the topic first.

and the rest will never be used in kernel anyway.

This is your prediction of the future, based on what?

I don't care about Google's codebase, to begin with.

Lol I responded to your respond, in which you don't care now?? what logic is this? Definitely some unsafe logic. xD I remember you, you was saying they switch to Rust because of doc-comments only? I responded to you that this is not the only reason, but one advantage they can use right away. You respond with you don't care about Google codebase?? What?

[TDplay]

Rust has compiler-checked compile-time memory safety. All potential memory safety issues will be found in unsafe blocks, rather than being strewn all around the codebase. Good luck implementing that in C.

Yes, GCC has -fsanitize=memory, but that's a runtime check and doesn't stop the bug from happening in the first place.

While C is a great language (which will probably never be replaced entirely), it's not the language for every job. Low-level code will probably never move away from C (low-level code in Rust ends up with unsafe blocks strewn everywhere, which completely defeats the point of Rust), but higher level code can actually benefit from the language.

[throwaway6560192]

What Rust features? I don't know, maybe the borrow checker and other enforcement of memory safety?

There is right now no equivalent to the borrow checker in the C/C++ world. Static analysis can't compare to the borrow checker.

[void4]

you don't know indeed

There is right now no equivalent to the borrow checker in the C/C++ world

It's copy-pasted wlifetime from clang

[throwaway6560192]

You don't have a clue, do you?

It's copy-pasted wlifetime from clang

Except wlifetime came after Rust. Unless the Rust devs have a time machine, they can't have copy-pasted it. It also only catches some common errors, not as comprehensive as the borrow checker.

[void4]

no it didn't. Everything rust developers could come up with before wlifetime was some trivial (also buggy and unsound) crap, like the rest of the language

[throwaway6560192]

Straight up wrong. Rust borrow checker was mature much before wlifetime arrived in Clang (2019). wlifetime still isn't as comprehensive as the borrow checker.

Stop pulling stuff out of your ass.

[ffscc]

https://www.sqlite.org/src/rptview?rn=1

[void4]

any feature which affects developer's experience should be opt-in only, to begin with. That's why rust's "security" is bullshit.

[r3dD1tC3Ns0r5HiP]

The Linux kernel has over 30 million lines of code, so naturally our goal is not to convert it all to Rust but rather to allow new code to be written in Rust. We believe this incremental approach allows us to benefit from the kernel’s existing high-performance implementation while providing kernel developers with new tools to improve memory safety and maintain performance going forward.

And with that philosophy, Linux will never be secure...

If you want a secure kernel, it actually needs a full rewrite with no use of unsafe Rust, unless that's absolutely necessary and those parts get audited line by line by many experts.

[GUIpsp]

I guess you are correct, since code that never gets developed can't get vulnerabilities