13 ms·

I wish that we had Rust 30 years ago. Many of these problems would have been solved by the ownership system.

klabb3 4y ago
It would be impossible to say because it depends on the hypothetical Rust implementation. A kernel needs a huge amount of unsafe, all of which is surface area for these types of bugs.
2OEH8eoCRo0 4y ago
We had Ada in 1980.
- keyle 4y ago
  I don't particularly know ADA, but are you implying that it solves the issues that C++ couldn't? If so, why didn't it take off like C++ did?
  - cjbgkagh 4y ago
    Ada has some really good synchronization primitives, I don’t know if that would have helped here as I haven’t looked at the problem that closely. I work at a much higher level so I lack the experience at this level. Ada was phased out for C++ primarily because the devs are cheaper.
  - naasking 4y ago
    Proprietary compilers, some limitations in the type system meant the standard library wasn't as useful even though it is a safer language as a result. The verbosity also turned me of initially.
    - kevin_thibedeau 4y ago
      It was also a bit of a PITA before Ada'95 and by which time C had won.
    - pjmlp 4y ago
      C and C++ also only had proprietary compilers, mostly. However both were born alongside UNIX and that helped C++ to be quickly adopted by all major C compiler vendors, whereas Ada was always something extra to pay on top. When targeting UNIX, with C and C++ compilers on the box, who is going to pay extra for the Ada compiler unless required to do so?
      - naasking 4y ago
        > C and C++ also only had proprietary compilers, mostly. I was thinking more in the 90s where GNU already had a freely available C compiler, but GNAT didn't get a free version until the late 90s, and even then it was built on a fork of gcc you had to download separately until like 2000. It was just a lot of work to get up and running, as opposed to the bundling of C/C++ compilers with Linux that was common, as you say. The initial C compatibility helped C++ a lot too.
        pjmlp 4y ago
        GCC only took off because Sun decided to split their UNIX into user and developer editions, and other UNIX vendors followed. Still same rule applies, when a UNIX shop paid for UNIX developer tooling, usually languages like Ada and Modula-2 weren't in the box, you needed to pay extra.
  - kergonath 4y ago
    It very much does. Ada has been designed for safety and concurrency, and for environments where failure is something to avoid at all costs. However, it still has issues of its own; no language is perfect and the best-suited for all use cases.
robocat 4y ago
This is not a standard memory leak, and would not have been avoided by using rust. Edited and re-edited: I was too quick to presume commenter was just spouting the common “rust is a panacea” theme. Kernels are all about “unsafe” concurrent access and reentrant code, so rust is not a panacea. For this case of multi-threaded/multi-process access (presumably from ring-0 kernel code accessing shared kernel memory), using rust primitives to help prevent race conditions could make sense (smart pointers), because the code is unlikely to be performance sensitive and the feature is there to protect against a fairly extreme corner case (crazy ad hoc GC for cyclic graph of processes sending each other file descriptors). Reliable discussion on rust for kernel drivers here: https://security.googleblog.com/2021/04/rust-in-linux-kernel.html https://security.googleblog.com/2021/04/rust-in-linux-kernel... Disclaimer: not a kernel nor rust dev. In past dabbled with embedded kernel debugging. I keep tweaking this edit, because it is complicated!
- tsimionescu 4y ago
  By my understanding, Rust's ownership model would prevent concurrent access to the socket buffer garbage collector data structures without proper synchronization, which was the source of this bug. This is in fact an example of a class of bug that Rust's compiler is uniquely able to protect from - other memory safe languages don't make guarantees about concurrent accesses at all - at least not Java, C#, Go, Python, Haskell, OCaml etc. Perhaps Ada does have something?
  - mhh__ 4y ago
    D sort of does. We have a type qualifier for shared data that is picky about accesses but it's not completely there yet i.e. still requires some knowledge.
  - azakai 4y ago
    > By my understanding, Rust's ownership model would prevent concurrent access to the socket buffer garbage collector data structures without proper synchronization Possibly. But the first question is whether the person writing this in Rust would have used unsafe. Without knowing more details here, it's hard for me to guess. > other memory safe languages don't make guarantees about concurrent accesses at all - at least not Java Well, Java does have synchronized methods. Those lock the entire class. You can imagine writing a "manager" class that encapsulates all the GC data structures here, and that would have made this perfectly safe in Java using existing language features. Of course, that would have been slower - so, again, it is tempting to use unsafe approaches, even in a memory-safe language like Java, but then you do risk bugs like this. But of course I do agree that Rust, even with some amount of unsafe, would be a far safer language than C!
wudangmonk 4y ago
Amen brother. Most people will claim that Rust would probably take years to compile on 30 yrd old hardware but I say to them "why is your heart so full of doubt?". You have to believe. The more you believe and trust Rust, the more limitless your possibilities become for your family, your career and your life!.
- isaacfrond 4y ago
  That made my day.
deleted 4y ago
[deleted]
bumblebritches5 4y ago
pjmlp 4y ago
We had Ada.

It would be impossible to say because it depends on the hypothetical Rust implementation. A kernel needs a huge amount of unsafe, all of which is surface area for these types of bugs.

2OEH8eoCRo0 4y ago

We had Ada in 1980.

keyle 4y ago
I don't particularly know ADA, but are you implying that it solves the issues that C++ couldn't? If so, why didn't it take off like C++ did?
- cjbgkagh 4y ago
  Ada has some really good synchronization primitives, I don’t know if that would have helped here as I haven’t looked at the problem that closely. I work at a much higher level so I lack the experience at this level. Ada was phased out for C++ primarily because the devs are cheaper.
- naasking 4y ago
  Proprietary compilers, some limitations in the type system meant the standard library wasn't as useful even though it is a safer language as a result. The verbosity also turned me of initially.
  - kevin_thibedeau 4y ago
    It was also a bit of a PITA before Ada'95 and by which time C had won.
  - pjmlp 4y ago
    C and C++ also only had proprietary compilers, mostly. However both were born alongside UNIX and that helped C++ to be quickly adopted by all major C compiler vendors, whereas Ada was always something extra to pay on top. When targeting UNIX, with C and C++ compilers on the box, who is going to pay extra for the Ada compiler unless required to do so?
    - naasking 4y ago
      > C and C++ also only had proprietary compilers, mostly. I was thinking more in the 90s where GNU already had a freely available C compiler, but GNAT didn't get a free version until the late 90s, and even then it was built on a fork of gcc you had to download separately until like 2000. It was just a lot of work to get up and running, as opposed to the bundling of C/C++ compilers with Linux that was common, as you say. The initial C compatibility helped C++ a lot too.
      - pjmlp 4y ago
        GCC only took off because Sun decided to split their UNIX into user and developer editions, and other UNIX vendors followed. Still same rule applies, when a UNIX shop paid for UNIX developer tooling, usually languages like Ada and Modula-2 weren't in the box, you needed to pay extra.
- kergonath 4y ago
  It very much does. Ada has been designed for safety and concurrency, and for environments where failure is something to avoid at all costs. However, it still has issues of its own; no language is perfect and the best-suited for all use cases.

robocat 4y ago

This is not a standard memory leak, and would not have been avoided by using rust. Edited and re-edited: I was too quick to presume commenter was just spouting the common “rust is a panacea” theme. Kernels are all about “unsafe” concurrent access and reentrant code, so rust is not a panacea. For this case of multi-threaded/multi-process access (presumably from ring-0 kernel code accessing shared kernel memory), using rust primitives to help prevent race conditions could make sense (smart pointers), because the code is unlikely to be performance sensitive and the feature is there to protect against a fairly extreme corner case (crazy ad hoc GC for cyclic graph of processes sending each other file descriptors). Reliable discussion on rust for kernel drivers here: https://security.googleblog.com/2021/04/rust-in-linux-kernel.html https://security.googleblog.com/2021/04/rust-in-linux-kernel... Disclaimer: not a kernel nor rust dev. In past dabbled with embedded kernel debugging. I keep tweaking this edit, because it is complicated!

tsimionescu 4y ago
By my understanding, Rust's ownership model would prevent concurrent access to the socket buffer garbage collector data structures without proper synchronization, which was the source of this bug. This is in fact an example of a class of bug that Rust's compiler is uniquely able to protect from - other memory safe languages don't make guarantees about concurrent accesses at all - at least not Java, C#, Go, Python, Haskell, OCaml etc. Perhaps Ada does have something?
- mhh__ 4y ago
  D sort of does. We have a type qualifier for shared data that is picky about accesses but it's not completely there yet i.e. still requires some knowledge.
- azakai 4y ago
  > By my understanding, Rust's ownership model would prevent concurrent access to the socket buffer garbage collector data structures without proper synchronization Possibly. But the first question is whether the person writing this in Rust would have used unsafe. Without knowing more details here, it's hard for me to guess. > other memory safe languages don't make guarantees about concurrent accesses at all - at least not Java Well, Java does have synchronized methods. Those lock the entire class. You can imagine writing a "manager" class that encapsulates all the GC data structures here, and that would have made this perfectly safe in Java using existing language features. Of course, that would have been slower - so, again, it is tempting to use unsafe approaches, even in a memory-safe language like Java, but then you do risk bugs like this. But of course I do agree that Rust, even with some amount of unsafe, would be a far safer language than C!

wudangmonk 4y ago

Amen brother. Most people will claim that Rust would probably take years to compile on 30 yrd old hardware but I say to them "why is your heart so full of doubt?". You have to believe. The more you believe and trust Rust, the more limitless your possibilities become for your family, your career and your life!.

isaacfrond 4y ago
That made my day.

deleted 4y ago

[deleted]

bumblebritches5 4y ago

pjmlp 4y ago

We had Ada.