4 ms·

Rustproofing Linux (Part 1/4 Leaking Addresses) (2023)

96 points by wglb 2y ago

jogger349 2y ago
[flagged]
smj-edison 2y ago
I think "pitfalls of porting Linux C to Rust" would be a more descriptive title, if verbose.
- carlmr 2y ago
  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.
  - smj-edison 2y ago
    Oh for sure! It does take understanding the idioms of the language you're porting to, and rust only guarantees memory safety when (iirc) 1. Being in an interrupt free and linear memory environment, and 2. All unsafe code maintains invariants (XOR mutability, etc). There's some others but I can't think of them off the top of my head. But, I wouldn't say this article is only about porting in general. It's very specific in using example drivers written for Linux (which is very different than application C) and showing pitfalls _specifically_ when going to rust. For example, in one of the later parts it talks about Rust mutexes, which are RAII. If you lock twice, you'll have a double fetch that can cause a race condition. That's not a general rule of thumb for code porting.
tetromino_ 2y ago
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.
- one_even_prime 2y ago
  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.
  - akira2501 2y ago
    > is figuring out how to educate other kernel developers about Rust Why have one class of logic errors when you can have two?
    - stouset 2y ago
      Why try to improve anything when you could just keep the original implementation around for forever?
      - throwawaymaths 2y ago
        As they say, if it ain't broke, don't fix it
iknowstuff 2y ago
This article is written ass backwards. 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.
fulafel 2y ago
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"?
alraj 2y ago
Link says 404 https://web.archive.org/web/20240828122042/https://research.nccgroup.com/2023/02/06/rustproofing-linux-part-1-4-leaking-addresses/ https://web.archive.org/web/20240828122042/https://research....
- wglb 2y ago
  Odd. A search also provides https://www.nccgroup.com/us/research-blog/rustproofing-linux-part-14-leaking-addresses/ https://www.nccgroup.com/us/research-blog/rustproofing-linux...
wglb 2y ago
Apparently link moved to https://www.nccgroup.com/us/research-blog/rustproofing-linux-part-14-leaking-addresses/ https://www.nccgroup.com/us/research-blog/rustproofing-linux...

96 points by wglb 2y ago

jogger349 2y ago

[flagged]

smj-edison 2y ago

I think "pitfalls of porting Linux C to Rust" would be a more descriptive title, if verbose.

carlmr 2y ago
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.
- smj-edison 2y ago
  Oh for sure! It does take understanding the idioms of the language you're porting to, and rust only guarantees memory safety when (iirc) 1. Being in an interrupt free and linear memory environment, and 2. All unsafe code maintains invariants (XOR mutability, etc). There's some others but I can't think of them off the top of my head. But, I wouldn't say this article is only about porting in general. It's very specific in using example drivers written for Linux (which is very different than application C) and showing pitfalls _specifically_ when going to rust. For example, in one of the later parts it talks about Rust mutexes, which are RAII. If you lock twice, you'll have a double fetch that can cause a race condition. That's not a general rule of thumb for code porting.

tetromino_ 2y ago

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.

one_even_prime 2y ago
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.
- akira2501 2y ago
  > is figuring out how to educate other kernel developers about Rust Why have one class of logic errors when you can have two?
  - stouset 2y ago
    Why try to improve anything when you could just keep the original implementation around for forever?
    - throwawaymaths 2y ago
      As they say, if it ain't broke, don't fix it

iknowstuff 2y ago

This article is written ass backwards. 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.

fulafel 2y ago

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"?

alraj 2y ago

Link says 404 https://web.archive.org/web/20240828122042/https://research.nccgroup.com/2023/02/06/rustproofing-linux-part-1-4-leaking-addresses/ https://web.archive.org/web/20240828122042/https://research....

wglb 2y ago
Odd. A search also provides https://www.nccgroup.com/us/research-blog/rustproofing-linux-part-14-leaking-addresses/ https://www.nccgroup.com/us/research-blog/rustproofing-linux...

wglb 2y ago

Apparently link moved to https://www.nccgroup.com/us/research-blog/rustproofing-linux-part-14-leaking-addresses/ https://www.nccgroup.com/us/research-blog/rustproofing-linux...