Summary: a naive port of a kernel driver from C to Rust can easily introduce information leak vulnerabilities, which in kernel-style C were automatically prevented by preprocessor trickery.
More like: the Linux kernel re-implementation of Rust "print" has a bug that causes it to not adhere to Linux kernel conventions.
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.
A higher level summary: A lot of institutional knowledge has been embedded into the C code over the years, sometimes in subtle ways, and a naive port to Rust can introduce security vulnerabilities if some of these subtleties get overlooked.
Should start with the last part which explains that they have the WritableToBytes trait - implementing it has to be marked unsafe because it has an explicit invariant: no padding.
When it’s not implemented on a type, you can’t pass it to the writer unless you do what they did and use two pointer casts within an unsafe block. So you don’t do that. Instead, you write the initialized parts of the struct individually. They’ll probably add a derive macro to make implementing something a safe equivalent of the trait trivial.
I think these are just general pitfalls that happen when you port something.
Also thinking everything is safe from a security perspective because you don't use the keyword `unsafe` seems kind of naive to me. For one safety and security are two separate issues. Also this assumes you really did not understand why Rust has the keyword in the first place and what it's used for.
Obviously Rust can't prevent all logic errors, and doesn't promise to. If you adhere to idiomatic Rust (e.g. using sum types to make impossible states not representable) you'll probably prevent quite a few. But if you port line by line it won't be idiomatic.
Rust does offer a lot of error checking at compile time that you only get at runtime with a combination of ASan, LSan, UBSan, TSan, MSan in C. But it doesn't mean you can stop thinking entirely.
The hidden unsafety in the pr_ macros (here under the heading Bonus Point for no unsafe) was interesting. I wonder if there's anything the compiler could do to detect this kind surprise-unsafety happening, for example a no-unsafe assertion in a source file.
Also, why doesn't the compiler know by default that the stack allocated struct is "MaybeUninit"?
[+] [-] tetromino_|1 year ago|reply
[+] [-] one_even_prime|1 year ago|reply
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.
[+] [-] sundarurfriend|1 year ago|reply
[+] [-] iknowstuff|1 year ago|reply
Should start with the last part which explains that they have the WritableToBytes trait - implementing it has to be marked unsafe because it has an explicit invariant: no padding.
When it’s not implemented on a type, you can’t pass it to the writer unless you do what they did and use two pointer casts within an unsafe block. So you don’t do that. Instead, you write the initialized parts of the struct individually. They’ll probably add a derive macro to make implementing something a safe equivalent of the trait trivial.
[+] [-] smj-edison|1 year ago|reply
[+] [-] carlmr|1 year ago|reply
Also thinking everything is safe from a security perspective because you don't use the keyword `unsafe` seems kind of naive to me. For one safety and security are two separate issues. Also this assumes you really did not understand why Rust has the keyword in the first place and what it's used for.
Obviously Rust can't prevent all logic errors, and doesn't promise to. If you adhere to idiomatic Rust (e.g. using sum types to make impossible states not representable) you'll probably prevent quite a few. But if you port line by line it won't be idiomatic.
Rust does offer a lot of error checking at compile time that you only get at runtime with a combination of ASan, LSan, UBSan, TSan, MSan in C. But it doesn't mean you can stop thinking entirely.
[+] [-] alraj|1 year ago|reply
https://web.archive.org/web/20240828122042/https://research....
[+] [-] wglb|1 year ago|reply
A search also provides
https://www.nccgroup.com/us/research-blog/rustproofing-linux...
[+] [-] fulafel|1 year ago|reply
Also, why doesn't the compiler know by default that the stack allocated struct is "MaybeUninit"?
[+] [-] wglb|1 year ago|reply
[+] [-] jogger349|1 year ago|reply
[deleted]