5 ms·

I don't think anyone's claiming you can't use your system's API in Rust, to do things like gain root privileges. Just that Rust makes memory bugs and race condi

I don't think anyone's claiming you can't use your system's API in Rust, to do things like gain root privileges. Just that Rust makes memory bugs and race conditions near impossible.

citizenterminal 10y ago
Rust doesn't prevent race conditions–it prevents data races. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
- gue5t 10y ago
  True. The indeterminism provided by letting the OS and cache coherence reorder thread execution and memory accesses in response to external factors is one of the reasons parallel execution can provide speedups in practice, so benign races are important to permit. But this is a data race: the mail program performs a check on some data (in the filesystem) to establish some precondition, and then a concurrent thread of execution (another process) mutates that data before the mail program acts on its (now invalidated) belief. LLVM wouldn't call it a data race, because to LLVM all system calls are essentially opaque. But if the filesystem only existed within your process, and were written in idiomatic Rust style, using structs, borrowing, mutability, and lifetimes, then the analogous bug (two threads racing and mutating the filesystem at once) would be prevented. The real villain here is shared mutable state; if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem.
  - steveklabnik 10y ago
    > on some data (in the filesystem) Traditionally, "data race" only refers to memory, not other forms of resources. So I agree with you that this is like a data race, but would dispute that it's actually a data race.
  - asveikau 10y ago
    > if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem. I think this is kind of absurd and my guess is you haven't worked on a filesystem driver. At a certain point there is value in admitting that race conditions are a part of the universe and developing strategies to deal with them, rather than waste a bunch of overhead trying to isolate a program from the real world or from itself. The semantics you seem to want would be really crazy for a filesystem.
asveikau 10y ago
The vulnerability described in the C program (race condition in filesystem which leads an attacker to write to a file they should have no access to) is absolutely possible to write in rust. I was attempting to parody the line that you see around here every time a vulernable C program is shown, that rust is magic pixie dust that removes all security issues. (This is exactly the type of bug that memory safe languages are still vulnerable to.) (One could argue setuid is the real problem though.)
- pjmlp 10y ago
  Yes safe systems programming languages are still open to logic errors, but getting rid of the memory corruption bugs that C spread into the world thanks to the adoption of UNIX is already an improvement over the daily CVE entries. Had AT&T charged UNIX at the same prices as the other OSes, instead of giving it for free to universities and I hardly believe C would matter.
  - qwertyuiop924 10y ago
    It's likely C, or something like it, would still matter. C, despite, and because, of its faults, fills an important niche: It's at a higher level of abstraction than assembler, but still provides the control you need for that very low-level code that you need to write things like operating systems. Yes, it isn't as safe as the Wirthian languages that you yourself prefer, and I will say that it certainly isn't ideal for most of the purposes it's put to, but if you want a high-level assembly language, than it works well, because that's pretty much what it is.
    - pjmlp 10y ago
      C has stopped being a high level Assembly for quite a while now. Most of the features people associate with C are compiler specific language extensions that any compiler writer can bother to add to his favourite language and not part of ANSI C. Inline Assembly, CPU intrisics, SIMD, calling conventions, out of order execution, hardware transaction memory, cache line control, GPU execution, attaching functions to interrupt handlers and so on. Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code. The only thing has going for it, us that thanks to the economics of free, we now have UNIX flavours everywhere. So we can only get rid of C when UNIX is not an option, and that is almost impossible. Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it. C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.

I don't think anyone's claiming you can't use your system's API in Rust, to do things like gain root privileges. Just that Rust makes memory bugs and race conditions near impossible.

citizenterminal 10y ago

Rust doesn't prevent race conditions–it prevents data races. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html

gue5t 10y ago
True. The indeterminism provided by letting the OS and cache coherence reorder thread execution and memory accesses in response to external factors is one of the reasons parallel execution can provide speedups in practice, so benign races are important to permit. But this is a data race: the mail program performs a check on some data (in the filesystem) to establish some precondition, and then a concurrent thread of execution (another process) mutates that data before the mail program acts on its (now invalidated) belief. LLVM wouldn't call it a data race, because to LLVM all system calls are essentially opaque. But if the filesystem only existed within your process, and were written in idiomatic Rust style, using structs, borrowing, mutability, and lifetimes, then the analogous bug (two threads racing and mutating the filesystem at once) would be prevented. The real villain here is shared mutable state; if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem.
- steveklabnik 10y ago
  > on some data (in the filesystem) Traditionally, "data race" only refers to memory, not other forms of resources. So I agree with you that this is like a data race, but would dispute that it's actually a data race.
- asveikau 10y ago
  > if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem. I think this is kind of absurd and my guess is you haven't worked on a filesystem driver. At a certain point there is value in admitting that race conditions are a part of the universe and developing strategies to deal with them, rather than waste a bunch of overhead trying to isolate a program from the real world or from itself. The semantics you seem to want would be really crazy for a filesystem.

asveikau 10y ago

The vulnerability described in the C program (race condition in filesystem which leads an attacker to write to a file they should have no access to) is absolutely possible to write in rust. I was attempting to parody the line that you see around here every time a vulernable C program is shown, that rust is magic pixie dust that removes all security issues. (This is exactly the type of bug that memory safe languages are still vulnerable to.) (One could argue setuid is the real problem though.)

pjmlp 10y ago
Yes safe systems programming languages are still open to logic errors, but getting rid of the memory corruption bugs that C spread into the world thanks to the adoption of UNIX is already an improvement over the daily CVE entries. Had AT&T charged UNIX at the same prices as the other OSes, instead of giving it for free to universities and I hardly believe C would matter.
- qwertyuiop924 10y ago
  It's likely C, or something like it, would still matter. C, despite, and because, of its faults, fills an important niche: It's at a higher level of abstraction than assembler, but still provides the control you need for that very low-level code that you need to write things like operating systems. Yes, it isn't as safe as the Wirthian languages that you yourself prefer, and I will say that it certainly isn't ideal for most of the purposes it's put to, but if you want a high-level assembly language, than it works well, because that's pretty much what it is.
  - pjmlp 10y ago
    C has stopped being a high level Assembly for quite a while now. Most of the features people associate with C are compiler specific language extensions that any compiler writer can bother to add to his favourite language and not part of ANSI C. Inline Assembly, CPU intrisics, SIMD, calling conventions, out of order execution, hardware transaction memory, cache line control, GPU execution, attaching functions to interrupt handlers and so on. Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code. The only thing has going for it, us that thanks to the economics of free, we now have UNIX flavours everywhere. So we can only get rid of C when UNIX is not an option, and that is almost impossible. Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it. C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.