4 ms·

My reading of this is a lot more generous to the maintainers and a lot less sympathetic to the author than yours is. The maintainers highlighted the problems an

My reading of this is a lot more generous to the maintainers and a lot less sympathetic to the author than yours is. The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. The author ate a lot of very senior people's time arguing instead of listening to them and learning from their experience and that was justifiably frustrating forcing much more direct feedback. The kind of mistake the author made - having to enforce at each individual syscall level instead of it being a protection on the memory itself enforced on all accesses - indicates a poor understanding of how to think about security and build security APIs which is a problem when you're proposing a security API. It's particularly impressive how misguided the patch is given that they took inspiration from the OpenBSD API implementation, changed both API & implementation, & then argued with both Linus and Theo who started Linux & OpenBSD respectively and were trying to give direct feedback about how OpenBSD is different and why it took the approach it did. Hopefully the author has taken the more forceful feedback as a learning opportunity about listening to feedback when the people giving it to you have a lot more experience. Or their team is coaching them about what went wrong now that this became so visible to learn what they got wrong. From Matthew Wilcox who is another senior Linux maintainer: > I concur with Theo & Linus. You don't know what you're doing. I think the underlying idea of mimmutable() is good, but how you've split it up and how you've implemented it is terrible. It's delivered directly and bluntly but it's not mean or personal. The author proposed a bad patch & argued from a position of ignorance.

jorvi 2y ago
> The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. Isn't that the Linux kernel in a nutshell? Of the top of my head I can name: - The zram maintainer that's for a few years been blocking the patches that add the zpool api to zram. This would go a long way to unifying zram and zswap in the future. - TuxOnIce being permablocked by some heels-in-sand maintainers until the kernel diverged to much and the patch writer gave up. This one would have fixed hibernation on Linux.. in other words, hibernation still sucks because of these maintainers. - Of course the trench warfare all the C-proficient maintainers are waging to chase all the Rust-in-Linux people away, lest they have to learn Rust. ~80% of CVEs are memory-related, so you could say that in say.. 10 years time, ~80% of the CVEs happening in the Linux kernel are the legacy of Ted & co.
- vlovich123 2y ago
  You can roughly be: 1. Wrong and ignorant 2. Wrong and knowledgeable 3. Right and ignorant 4. Right and knowledgeable There's also when there's just a disagreement of opinion because you weight the tradeoffs differently, in which case there's less of a right or wrong. The main difference is that in those cases the people involved were in camps 2-4 or simply weighted tradeoffs differently. In this case the author seemed much more clearly in camp 1. Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. Or maybe it would have been hunky dorry. But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). As for Rust-in-Linux, it sounds like your not actually up to date [1]. I'll forgive Ted's emotional volatility at the infamous filesystem talk as he's been much more calm about it now: > There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn. I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. There's going to be resistance and push back and some of it will feel unfair to the Rust folks and some will feel unfair to the C folk and both will be right. [1] https://lwn.net/Articles/991062/ https://lwn.net/Articles/991062/
  - jorvi 2y ago
    > But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). I was speaking in general terms, of how recognizable the "heels-in-the-sand" attitude is. In this particular case yes, it does sound right that the current "mseal" proposal / patches is not up to snuff. Edit: also reading through it again, props to Theo's response. Stern but with a lot of edification. > Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. The nice thing about TuxOnIce is that it would have pushed large parts of hibernation into userspace, which would have made it much more versatile and much easier to iterate on. > As for Rust-in-Linux, it sounds like your not actually up to date [1]. One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. How is that "some of it will feel unfair to the Rust folks and some will feel unfair to the C folk"? > I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. [0]https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533

jorvi 2y ago

> The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. Isn't that the Linux kernel in a nutshell? Of the top of my head I can name: - The zram maintainer that's for a few years been blocking the patches that add the zpool api to zram. This would go a long way to unifying zram and zswap in the future. - TuxOnIce being permablocked by some heels-in-sand maintainers until the kernel diverged to much and the patch writer gave up. This one would have fixed hibernation on Linux.. in other words, hibernation still sucks because of these maintainers. - Of course the trench warfare all the C-proficient maintainers are waging to chase all the Rust-in-Linux people away, lest they have to learn Rust. ~80% of CVEs are memory-related, so you could say that in say.. 10 years time, ~80% of the CVEs happening in the Linux kernel are the legacy of Ted & co.

vlovich123 2y ago
You can roughly be: 1. Wrong and ignorant 2. Wrong and knowledgeable 3. Right and ignorant 4. Right and knowledgeable There's also when there's just a disagreement of opinion because you weight the tradeoffs differently, in which case there's less of a right or wrong. The main difference is that in those cases the people involved were in camps 2-4 or simply weighted tradeoffs differently. In this case the author seemed much more clearly in camp 1. Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. Or maybe it would have been hunky dorry. But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). As for Rust-in-Linux, it sounds like your not actually up to date [1]. I'll forgive Ted's emotional volatility at the infamous filesystem talk as he's been much more calm about it now: > There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn. I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. There's going to be resistance and push back and some of it will feel unfair to the Rust folks and some will feel unfair to the C folk and both will be right. [1] https://lwn.net/Articles/991062/ https://lwn.net/Articles/991062/
- jorvi 2y ago
  > But it kind of doesn't matter because the author in this case was clearly wrong (i.e. the patch wouldn't have achieved the goal it set out to do and would have predictably caused vulnerabilities to become possible in the future as the kernel evolved). I was speaking in general terms, of how recognizable the "heels-in-the-sand" attitude is. In this particular case yes, it does sound right that the current "mseal" proposal / patches is not up to snuff. Edit: also reading through it again, props to Theo's response. Stern but with a lot of edification. > Regarding the claim that "this one would have fixed hibernation on Linux" - maybe, but it's hard to evaluate a road not taken. It could have made other tradeoffs or caused other issues down the road that aren't visible to you right now because it didn't get mainlined or maybe hibernation would still have been broken. The nice thing about TuxOnIce is that it would have pushed large parts of hibernation into userspace, which would have made it much more versatile and much easier to iterate on. > As for Rust-in-Linux, it sounds like your not actually up to date [1]. One of the main Rust spearhead developers felt the need to quit, and almost immediately thereafter Asahi Lina posted an article about how "a subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible." By my count that is 0-2. How is that "some of it will feel unfair to the Rust folks and some will feel unfair to the C folk"? > I'd say "trench resistance" not warfare. The Rust movement is trying to shift the daily work of ~15k developers in a mostly bazaar development model. They're not trying to shift the daily work of ~15k developers. They're asking for some shims, stubs, adaptations, and some general flexibility & willingness. They're not expecting everyone to write Rust within the next 18 months. [0]https://vt.social/@lina/113045455229442533 https://vt.social/@lina/113045455229442533