[HN Gopher] The quantum state of Linux kernel garbage collection
___________________________________________________________________
The quantum state of Linux kernel garbage collection
Author : mfrw
Score : 57 points
Date : 2022-09-03 02:26 UTC (1 days ago)
(HTM) web link (googleprojectzero.blogspot.com)
(TXT) w3m dump (googleprojectzero.blogspot.com)
| faisal_ksa wrote:
| I wish that we had Rust 30 years ago. Many of these problems
| would have been solved by the ownership system.
| robocat wrote:
| This is not a standard memory leak, and would not have been
| avoided by using rust.
|
| Edited twice: 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 access, using
| rust primitives to prevent race conditions would make sense,
| because the code is unlikely to be performance sensitive (no
| need for unsafe) and the feature is there to protect against a
| fairly extreme corner case. Reliable discussion on rust for
| kernel drivers here:
| https://security.googleblog.com/2021/04/rust-in-linux-kernel...
| tsimionescu wrote:
| 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__ wrote:
| 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 wrote:
| > 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!
| elcritch wrote:
| Robocat is probably correct. Rust doesn't prevent race
| conditions, just data races. For example a Rust CVE due to
| a race condition: https://www.cybersecurity-
| help.cz/vdb/SB2022012101
|
| This CVE appears to be due to a race condition despite
| using atomics, so likely this could've happened in Rust
| code. Really to implement this sort of GC I'd wager that
| unsafe rust would also be required unless an entirely
| different algorithm was used.
| azakai wrote:
| That's my guess too. These GC data structures need to be
| accessed from multiple threads, if I understood TFA,
| which means they won't compile normally in Rust. That is
| exactly Rust doing its job and preventing bugs, but it
| means that the developer then needs to use unsafe (or
| find a workaround with runtime checks, at the cost of
| overhead).
| 2OEH8eoCRo0 wrote:
| We had Ada in 1980.
| wudangmonk wrote:
| 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!.
| klabb3 wrote:
| 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.
| targ65 wrote:
| " This issue was initially discovered in 2016 by a RedHat kernel
| developer and disclosed in a public email thread, but the Linux
| kernel community did not patch the issue until it was re-reported
| in 2021."
|
| Insane.
___________________________________________________________________
(page generated 2022-09-04 23:00 UTC)