Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by Tuna-Fish on Tuesday August 27, 2024 @07:03PM
(#41374194)
> article authors are surprised the unsafe keyword is not required
The often surprising part of raw pointers to system programmers newly dabbling in Rust is that every operation on them is safe, except for deref. You can freely take addresses and do pointer arithmetic on them without having to deal with unsafe, and only have to tell the compiler that you know what you are doing when you either load or store something through them.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by zesterer on Wednesday August 28, 2024 @08:48AM
(#41378887)
That's... simply not true. Pointer arithmetic is not, in general, safe. Example: https://doc.rust-lang.org/std/primitive.pointer.html#method....
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by gpm on Sunday September 01, 2024 @11:08AM
(#41417581)
Eh... the ptr::add function exists if you want to make extra promises to the compiler to let it optimize better, but if you don't a safe version exists: https://doc.rust-lang.org/std/primitive.pointer.html#method....
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by akira2501 on Tuesday August 27, 2024 @06:13PM
(#41373739)
> is figuring out how to educate other kernel developers about Rust
Why have one class of logic errors when you can have two?
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by itishappy on Tuesday August 27, 2024 @07:27PM
(#41374382)
Why have any? Zero errors is trivially achievable by not writing code.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by dartos on Tuesday August 27, 2024 @09:53PM
(#41375222)
What if not writing code is an error in and of itself?
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by bravetraveler on Thursday August 29, 2024 @08:15AM
(#41390006)
If it's worth doing it's already done
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by oneshtein on Wednesday August 28, 2024 @03:35AM
(#41376946)
It's true, /bin/true.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by stouset on Tuesday August 27, 2024 @06:36PM
(#41373980)
Why try to improve anything when you could just keep the original implementation around for forever?
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by throwawaymaths on Tuesday August 27, 2024 @08:28PM
(#41374805)
As they say, if it ain't broke, don't fix it
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by stouset on Tuesday August 27, 2024 @10:20PM
(#41375379)
The evidence that C is broke is pretty overwhelming at this point.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by atoav on Wednesday August 28, 2024 @06:20AM
(#41377943)
For varying definitions of "not broke".
Thinking about my uncle, running Windows 97 in his company.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by akira2501 on Wednesday August 28, 2024 @05:21AM
(#41377628)
The El Camino was supposed to be an improvement. A combination between a car and a truck. It turns out it was not an improvement. It's better to just have a car or a truck. Cutting them in half and then weirdly stitching the two parts together creates a Frankenstein nightmare of bad engineering. Which even the best explanations on the planet can't fix.
Re:Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)
by Wowfunhappy on Wednesday August 28, 2024 @06:57AM
(#41378169)
^ If I can try to steel man this, it may be that having two different languages is simply worse than having one, even if the one language is non-optimal. Sure, if you were starting Linux today you wouldn't choose C, and hopefully Linux won't be the last operating system to ever exist, and the next one can use Rust. But Linux uses C, and no one is contemplating a full rewrite, so it's best to stick with C.
I have no idea if this is true, I am very much not a kernel developer.
I'd expect that now that the bug has been reported, it'd be fixed by just hashing pointer addresses before printing them.
I also expect that "reimplementing X in a different programming language" introduces logic bugs, like the one above, and that those involved have deemed what they get out of it worth the effort of hashing these sort of bugs long term.
From the kernel pov, all of these bugs are safety issues, so the article authors are surprised the unsafe keyword is not required to introduce them, but from Rust's pov, they are just logic bugs, which safe Rust does not protect against. One of the main challenges those working on Rust in the kernel will have is figuring out how to educate other kernel developers about Rust (what it does and does not protect against, setting the right expectations, etc.). I think these articles are a great step in that direction.