4 ms·

Thought the same, because if you look at what he found.. >ranging from NULL pointer dereferences, to memory fenceposts visible only under ASAN or Valgrind, to

by copx 11y ago

Thought the same, because if you look at what he found.. >ranging from NULL pointer dereferences, to memory fenceposts visible only under ASAN or Valgrind, to pretty straightforward uses of uninitialized pointers (link), bogus calls to free() (link), heap buffer overflows (link), and even stack-based ones (link). .. it seems that all those bugs are not even possible in Rust.

steveklabnik 11y ago
... in safe Rust, yes. But Rust isn't perfect, we _will_ have these kinds of issues crop up, especially with regards to unsafe code. Rust will significantly reduce these kinds of issues, but not completely eliminate them. There is no silver bullet. We've just started unleasing afl on Rust code, and it can still find issues: https://github.com/rust-lang/rust/issues/24276 https://github.com/rust-lang/rust/issues/24276
- kibwen 11y ago
  Let it be said that the Rust community believes in defense-in-depth. A low-level language with safe defaults is only one piece of the equation; a complement rather than a supplement to testing, auditing, fuzzing, sandboxing, and so on.
- chubot 11y ago
  Is the stack trace saying that the Rust parser tickles a bug in jemalloc or somehow uses it unsafely? A parser (which uses malloc) seems like a pretty basic use case for 100% safe code. When I think of unsafe code, I think of needing to make raw syscalls, libc calls, or inline assembly. Not string manipulation and malloc. I am not super familiar with Rust, but I imagine you don't have to use unsafe {} every time you need to malloc, right?
  - kibwen 11y ago
    The only reason that the parser was using unsafe code is because it is an extremely old part of the codebase, and likely required the unsafe blocks to hack around some deficiency in the compiler from Rust 0.3 or alike. Recent efforts to overhaul the parser have reduced this dramatically: there are two legitimate remaining uses of `unsafe` (dealing with libc stuff), and four uses of `unsafe` that all have associated FIXMEs.
  - steveklabnik 11y ago
    Kibwen is correct with regards to the parser, but I'd also like to mention that in Rust, you generally don't call malloc yourself. It's actually not even possible in stable Rust, though a high priority API we'd like to stabilize.

by copx 11y ago

steveklabnik 11y ago

... in safe Rust, yes. But Rust isn't perfect, we _will_ have these kinds of issues crop up, especially with regards to unsafe code. Rust will significantly reduce these kinds of issues, but not completely eliminate them. There is no silver bullet. We've just started unleasing afl on Rust code, and it can still find issues: https://github.com/rust-lang/rust/issues/24276 https://github.com/rust-lang/rust/issues/24276

kibwen 11y ago
Let it be said that the Rust community believes in defense-in-depth. A low-level language with safe defaults is only one piece of the equation; a complement rather than a supplement to testing, auditing, fuzzing, sandboxing, and so on.
chubot 11y ago
Is the stack trace saying that the Rust parser tickles a bug in jemalloc or somehow uses it unsafely? A parser (which uses malloc) seems like a pretty basic use case for 100% safe code. When I think of unsafe code, I think of needing to make raw syscalls, libc calls, or inline assembly. Not string manipulation and malloc. I am not super familiar with Rust, but I imagine you don't have to use unsafe {} every time you need to malloc, right?
- kibwen 11y ago
  The only reason that the parser was using unsafe code is because it is an extremely old part of the codebase, and likely required the unsafe blocks to hack around some deficiency in the compiler from Rust 0.3 or alike. Recent efforts to overhaul the parser have reduced this dramatically: there are two legitimate remaining uses of `unsafe` (dealing with libc stuff), and four uses of `unsafe` that all have associated FIXMEs.
- steveklabnik 11y ago
  Kibwen is correct with regards to the parser, but I'd also like to mention that in Rust, you generally don't call malloc yourself. It's actually not even possible in stable Rust, though a high priority API we'd like to stabilize.