Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

[moltonel]

It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)

Agreed, FSVO "popular". There doesn't seem to be any shortage of people wanting to contribute Linux-in-Rust work, but they'll remain outnumbered by Linux-in-C developers in the foreseeable future, How much of a problem that'll be remains to be seen, and will certainly depend on the various subsystem maintainers' policies.

For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
(personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

Disagree, this doesn't work for C++ either. C++ has its own set of gotchas, it's not just API-level differences you can look up in a reference. If anything, the fact that Rust doesn't look like C makes it a better candidate than C++ because it'll avoid overconfident C developers thinking they can write good C++.

At $DAYJOB I mentor new recruits on both large C++ and Rust projects, and I have less trouble accepting Rust merge requests than C++ ones. Rust usually has tighter APIs, enabling devs to reason more locally without having to check foreign code or manually uphold invariants as much as C++. Rust is ultimately a simpler language than C++ (Rust's initial learning curve is notoriously steep, but C++'s learning curve keeps climbing for years), making training less costly.

[ultimA]

And in turn many Rust projects end up being riddled with memory-safety issues like other projects.

Now don't mistake me. I'm not saying this is the destiny of all Rust projects. Of course it is possible to write Rust code which is completely safe. Projects that are nicely self-contained, don't have to interact with anything, are not safety-critical, are not performance-critical... whether a specific project, like the Linux kernel, checks these criteria, is another question.

But writing completely safe code under certain conditions by following certain coding standards is nothing alien to a whole lot of other programming languages either.

[ultimA]

I'm arguing: if you want safe code, don't use unsafe. Nothing more, nothing less.

Yes, now go and tell this kernel developers. Or to Mozilla. Or to all crate developers who have already committed this "crime" numerous times. What you are saying is irrealistic and oblivious to practice and reality. Unsafe code does get written a lot and it must be. And in turn many Rust projects end up being riddled with memory-safety issues like other projects.

[oleid]

Yes I even said myself that many of these are in unsafe code. But that doesn't mean the problems don't exist, that's just hushing up about them. The fact is in Rust you will have these problems too, because as real-life projects have proven repeatedly, unsafe does and must get written a lot. You're basically arguing "in Rust you can categorically avoid some types of errors by staying clear of specific features".

I'm arguing: if you want safe code, don't use unsafe. Nothing more, nothing less.

Well guess what, that way you can guarantee memory-safety in C++, C#, and many other languages too. In C++ if you avoid raw pointers and stick to a defined set std:: interfaces you will have no memory-related issues.

And avoid all references. Classic example is: get reference to vector element, push to vector, access reference.

[ultimA]

Well, you claimed something and didn't back it up.

The linked bug reports is https://bugzilla.mozilla.org/show_bug.cgi?id=1690718

It says: "Potential crash when an audio stream stops."

The CVE summary states it is a memory corruption bug. How it comes to be is irrelevant.

• If you do an "out of bounds" write in a vector in rust, it will crash the program. The std library makes sure of that. If your code produces out-of-bounds, it will compile, but not run. In c++ those will get unnoticed if you use [], but will be caught if you use at().
• So yes, you can program those "out-of-bounds", but it is a logic error, no unsafety, as the oob is caught at run time.
• same goes for double drop; It is a huge difference if your program will be terminated in case of such bugs or silently go on.

Not being able to continue execution at the same time makes Rust unsuited for critical infrastructure categorically.

• uninitialized memory you can only get from within unsafe code. Yes, you can write memory safety bugs in unsafe code.
• same goes for memory corruption
• use after free is prevented in safe code at compile time
• null pointer de-reference can also only happen in usafe code

Nobody said you cannot program safety bugs in usafe code, I'm sorry.

See above. Nobody claimed that you cannot program unsafe code in unsafe environments. Some pages ago, people said those bugs will happen at the C/interop layer.
Other people think they need unsafe code in their crate to do something fast. But usually this is not required.
There are even tools which list if your dependencies use unsafe code at all.

Again, you can do many things in unsafe code, which will break safety guarantees. In safe code, if you access a vector "out of bounds" your program will panic (at the moment). This is also a way to prevent unsafety - as a last resort. If this is not acceptable, you can use the getters, which check bounds and provide an optional reference.

The bottom line is: when using rust, stick to safe code as much as possible.

Yes I even said myself that many of these are in unsafe code. But that doesn't mean the problems don't exist, that's just hushing up about them. The fact is in Rust you will have these problems too, because as real-life projects have proven repeatedly, unsafe does and must get written a lot. You cannot say "Well, don't write code like that", because that's not realistic and it's not how things work in practice. You're basically arguing "in Rust you can categorically avoid some types of errors by staying clear of specific features". Well guess what, that way you can guarantee memory-safety in C++, C#, and many other languages too. In C++ if you avoid raw pointers and stick to a defined set std:: interfaces you will have no memory-related issues. In C# if you avoid unsafe contexts and mark your code #nullable enable then you'll have no memory issues. And so on. How come you accept the same arguments for Rust but not for other languages? That's a typical tell of an over-hyped crowd.

[oleid]

As you command, my lord. CVE-2021-23987. Purely rust, memory corruption.
Too bad you didn't check all. You cannot just check a small portion of something and expect that your observings are valid for the whole lot greater whole. Who's guesstimating now?

Well, you claimed something and didn't back it up.

The linked bug reports is https://bugzilla.mozilla.org/show_bug.cgi?id=1690718

It says: "Potential crash when an audio stream stops."

The problem is that they didn't wait for all clients to disconnect before stopping a server.
Classic logic error.

What? I'm sorry to call this out loud but now you're just BS. That list is mostly about memory issues. "out-of-bounds write", "double-drop". "drop of uninitialized memory", "sensitive information from uninitialized memory", "memory corruption", "use-after-free", "NULL pointer dereference". Many-many of each type.

• If you do an "out of bounds" write in a vector in rust, it will crash the program. The std library makes sure of that. If your code produces out-of-bounds, it will compile, but not run. In c++ those will get unnoticed if you use [], but will be caught if you use at().
  So yes, you can program those "out-of-bounds", but it is a logic error, no unsafety, as the oob is caught at run time.
• same goes for double drop; It is a huge difference if your program will be terminated in case of such bugs or silently go on.
• uninitialized memory you can only get from within unsafe code. Yes, you can write memory safety bugs in unsafe code.
• same goes for memory corruption
• use after free is prevented in safe code at compile time
• null pointer de-reference can also only happen in usafe code

Nobody said you cannot program safety bugs in usafe code, I'm sorry.

As seen above, you've been proven wrong about this. Rust code can and will have memory issues too, even a significant amount, as CVE reports, real-life codebases, and statistical evidence all show.

See above. Nobody claimed that you cannot program unsafe code in unsafe environments. Some pages ago, people said those bugs will happen at the C/interop layer.
Other people think they need unsafe code in their crate to do something fast. But usually this is not required.
There are even tools which list if your dependencies use unsafe code at all.

Over my past couple of posts, I've provided examples for each. You keep repeating about how sure you are in Rusts memory safety, but this is now clearly based on pure belief, ignoring the numerous counterexamples in the wild.

Again, you can do many things in unsafe code, which will break safety guarantees. In safe code, if you access a vector "out of bounds" your program will panic (at the moment). This is also a way to prevent unsafety - as a last resort. If this is not acceptable, you can use the getters, which check bounds and provide an optional reference.



The bottom line is: when using rust, stick to safe code as much as possible.

[ultimA]

[LIST=1][*]You didn't provide rust CVEs for firefox, just some statistics. I checked a few CVEs and they are all in C++ code. So no, guesstimating doesn't help. Provide me at least one about rust code which is about memory unsafety. Or at least one about rust code, if you don't find any with memory unsafety.

As you command, my lord. CVE-2021-23987. Purely rust, memory corruption.
Too bad you didn't check all. You cannot just check a small portion of something and expect that your observings are valid for the whole lot greater whole. Who's guesstimating now?

Not all CVEs are about memory unsafety. But in C++ most are according to the stats you quoted.

I never said all CVEs are memory unsafety. I'm talking about specifically those CVEs that are memory unsafety. And as clearly shown by the statistics, code which has a lot of Rust doesn't necessarily has less memory-unsafety issues at all.

The rust CVEs about the packages on crates.io are not about memory unsafety. Those are bad bugs fore sure, but not about memory unsafety. That is something entirely different.

What? I'm sorry to call this out loud but now you're just BS. That list is mostly about memory issues. "out-of-bounds write", "double-drop". "drop of uninitialized memory", "sensitive information from uninitialized memory", "memory corruption", "use-after-free", "NULL pointer dereference". Many-many of each type. How come any of these are not about memory safety? And surprisingly, while many of them are, a significant portion is not even in unsafe code. You can check for yourself, I did.

I don't argue that there are no bugs in firefox's rust code. And I'm positive you'll find crashes in rust code. Or maybe even CVEs where some parser did something stupid. But I'm positive you find none about memory unsafety. And that was all that was ever promised.

As seen above, you've been proven wrong about this. Rust code can and will have memory issues too, even a significant amount, as CVE reports, real-life codebases, and statistical evidence all show. Over my past couple of posts, I've provided examples for each. You keep repeating about how sure you are in Rusts memory safety, but this is now clearly based on pure belief, ignoring the numerous counterexamples in the wild.

[NobodyXu]

Imho there are several issues with rust:
- It's much less popular than c. This means even more difficult to find good maintainers. (without maintainers code probably gonna be quickly removed)
- For example in case of c++ language, developers who know c can extract parts which they don't understand and check them on cppreference.com This doesn't work with rust. (I agree that using directly all of c++ isn't also good option for kernel)
- (personal opinion) Rust and stuff around rust isn't mature (enough) yet. Project in which you can quickly put hotfixes - yes, large codebase with relatively slow release cycle - no,

About the second point, I would sat it is the complete opposite.

c++ as a language is much more complex than c or rust and checking cppreference alone would take you a lot of time.

For example, there are at least 3 ways (4 in c++20) to initialize objects and the list initialization is really similar to initializer list initialization.

Move semantics, is also a problem since it doesn’t specify whether an object is still valid and can be reused after another object moved from it and it requires additional attention of the code reviewers to ensure that it is not misused.

Template is another complex language structure of C++ and often responsible for generating unreadable compile tome error.

It isn’t until C++20 do we get concept checking support in the language level, and guess what, we instantly got another gotcha https://quuxplusone.github.io/blog/2...s-chest-mimic/

Even without this gotcha, c++20 has not yet gained full support from gcc and clang.

[oleid]

If you already think cargo is bad, then you will be surprised when LLVM becomes a kernel dependency.

If we are lucky, by the time rust is needed for building the kernel, we have a gcc based rust implementation.

[Alexmitter]

Oh please don't add fucking cargo as a kernel dependency. Rust, ok if it helps, but cargo is literally the definition of distro-unfriendly software.

If you already think cargo is bad, then you will be surprised when LLVM becomes a kernel dependency.

Lets see how powerful Google has become in the linux space, if they are able to force the LLVM trash onto us then they already won.