-12
Unsafe Rust: living up to its name (lemmy.sdf.org)
submitted 10 months ago by to c/programmer_humor@programming.dev
11 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 43 points 10 months ago* (last edited 10 months ago) (7 children)

Wait, is rust supposed to have intrinsic race condition protection? I thought its big feature was figuring out freeing memory for the dev instead of relying on runtime solutions or manual instructions... If it's not supposed to magically fix possible race conditions, I don't know how this issue is the language's fault.

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [–] 84 points 10 months ago (2 children)

    It’s not. It’s literally code in an unsafe block. The OP is either trolling or actually ignorant.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [+] [S] -26 points 10 months ago (1 child)

    https://doc.rust-lang.org/nomicon/races.html

    Safe Rust guarantees an absence of data races

    I know that it was unsafe block in this CVE, but the irony of the situation is funny.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 64 points 10 months ago

    Not only unironic but explained in the doc you referenced:

    “However Rust does not prevent general race conditions.

    This is mathematically impossible in situations where you do not control the scheduler, which is true for the normal OS environment.”

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 10 months ago (3 children)

    It is, in large part. The rules on ownership and borrowing mean that it is not supposed to be possible to change memory that something else can be concurrently reading from. That means you are forced to obtain references through protective mechanisms, which should protect from race conditions.

    All of that can go out of the window if you use unsafe.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 10 months ago (2 children)

    Note how the ticket cited is in an unsafe block, because it uses the OS scheduler, not its own. It is not Rust's fault.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 10 months ago

    Rust doesn't have a scheduler.
    The issue is the false assumption, that the remove operation can safely be done without taking a lock. This can be done in some specific data structures using atomic operations, but here the solution was to just take the lock. The same thing could have happened in a C code base but without the unsafe block indicating where to look for the bug.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 10 months ago

    Yeah, I'm not saying it's rust's fault. Restricting this to unsafe makes it a lot easier to reason about where such problems can occur.

    I just don't think anyone should give the impression that rust's memory safety is not about race conditions.

  • permalink
  • fedilink
  • source
  • parent