If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Latest Patches Sent Out For Adding Rust Support To The Linux Kernel
But is Rust's security really that much better? -O3 is irrelevant (I don't care about that either), but as for security, real world shows Rust's most advertised feature, its "better security compared to C++" is very limited and over-estimated. There is no shortage of memory memory-related CVEs in Rust crates, both double-drops/frees and dereference of invalid memory. See link below.
Or even more shocking, Firefox has about 20% of its native code in Rust, yet the share of memory-related CVEs (percentage-wise) is basically still the same as in any other non-Rust project (about 70%).
Yes it’s still much better because those double frees are only happening in unsafe blocks, so unlike C, in Rust you know where to look if there are problems.
Basically it’s not in the Rust code, it’s in the parts marked unsafe because you are doing C like things in them, such as manual pointer manipulation.
However, the memory-safety difference between idiomatic Rust and idiomatic C++ is minimal, while both being easy to develop for.
with idiomatic rust code you mean 'restricting to safe rust?
Considering C++ - no, C++ is not as safe. Not even if you only use modern C++17 code. I program c++ as a day job for many years and I think I know what I'm talking about as I know rust as well.
To sum up my two biggest concerns:
* C++ won't stop you from reading memory from Thread A while writing from Thread B. rust does, at compile time.
* C++ won't stop you from using references, which became invalid.
And the worst part is: neither the compiler nor clang-tidy will complain.
Now you could argue: well, that stuff is easy to get right in the first place. I agree, most of the time people do. But what happens if after some time people refactor, the behaviour changes and now you have another thread and forgot to add mutexes or mutate some container while keeping the reference? Bam, crash!
Rust wouldn't compile the refactored code, that's an advantage.
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,
What slow release cycle? I receive kernel .x updates very frequently.
Also, if C maintainers are so easy to find, why don't you go and tell the SystemD folks? 'Cause they claim it's hard to find C maintainers, but clearly that's a bad excuse 'cause *you* can just pull them out of a can, right?
Idiomatic Rust code typically uses unsafe in the following cases
1. C FFI , in which case if you get a memory leak its actually because of C not Rust
2. Memory mapped IO/hardware interfaces
So I am sorry but you are spreading grade A bullshit, because if there are "memory safety issues" in typical Rust code, you know its because of some underlying C library or because you are interfacing the hardware. What you do know is that the 70-100% of the rest of your code is memory safe, unlike the 0% you have with C (unless you are using one of those formally verified C subsets with a theorem prover).
I never compared Rust to C. I agree 100%, C is ridiculously bad in this aspect. However, the memory-safety difference between idiomatic Rust and idiomatic C++ is minimal, while both being easy to develop for. Mind you, idiomatic C++ code is not the same today as it was 10 years ago (not even sure if "idiomatic C++" existed 10 years ago - today it does). People who think everything needs to be rewritten in Rust and that will bring us salvation are wrong on two fronts: 1) it won't, and 2) easy memory-safe programming existed even before Rust. Not in C, that is true.
@NobodyXu @moltonel
as I written earlier I don't think c++ on its own is good solution. Somehow c++ is still missing option to disable features, for example compilers sees `std::thread` or raw copy constructor then it stops compilation. Also approach to undefined behavior, "it cannot happen so let's optimize" not so often is bad.
Maybe I shouldn't have used c++ as comparison point. Yeah, c++ is tricky and it's super easy for c developer to make a bug, (wanted to point that some smaller fixes can be checked by c developer).
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.
True, but usually you can contain it and know exactly where to look for
writing completely safe code under certain conditions by following certain coding standards is nothing alien to a whole lot of other programming languages either.
Absolutely. The debate is over what those conditions are, and how costly they are to implement. Seasoned C++ devs seem particularly prone to underestimating the later.
Leave a comment: