> Sounds as argument against big kernel and in favor more isolated drivers, and against "hyper-privileged" software in general...
Which is what macOS did, and why this can't happen on the macOS version of crowdstrike (it uses userspace drivers).
Linux has similar mechanisms, but can't discourage kernel drivers by policy like macOS did since it's not as tightly controlled, so CrowdStrike on Linux still uses a kernel driver even though it could choose not to, because they suck.
> Kernel could unlock all mutexes on process death (and even if process leaked mutexes lock without crash), same way as file handles freed even if you use kill command on process....
No. If a mutex is locked then there is no guarantee that the data protected by it is in a consistent state. You can't just "unlock all mutexes", then you just get data corruption which is worse than the partial deadlocks. Mutexes are low-level constructs. The whole point/job of the kernel is to keep track of resources in a safe manner so this can be done for userspace handles like file descriptors. The buck stops somewhere and within the kernel it is impossible to do this because at the end of the day there has to be *some* code in charge of atomicity/consistency for resource state and *that* code itself cannot be freely interruptible.
> At userspace it resembles how nodejs domains used to intercept error to prevent ungraceful process crash.
... and this works because Javascript is a high-level, memory-safe language. You can't do this with C.
Hector Martin /
npub1qk…9azpx
2024-07-20 15:12:44
in reply to nevent1q…q27e
Author Public Key
npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpxPublished at
2024-07-20 15:12:44Event JSON
{
"id": "825ec8cccade88b821fb9dccad27fb28ef302d84c651700b4468a8573f932254",
"pubkey": "058a6d106c5e6719008ce4db3f64c846caf49925227a39533d12a846fbab21ee",
"created_at": 1721488364,
"kind": 1,
"tags": [
[
"p",
"058a6d106c5e6719008ce4db3f64c846caf49925227a39533d12a846fbab21ee"
],
[
"proxy",
"https://social.treehouse.systems/@marcan/112819461487847041",
"web"
],
[
"e",
"fa9d6ef9ac8552ce088e83926f2a2e750a20fe430f71755e0498db3a059fabda",
"",
"root"
],
[
"p",
"2ceb75c8271582855ec79d56c3f90da020e88de9f98dd6e76a1c7e436d5da02a"
],
[
"e",
"4c1a158ad9bcf0eaee61d45f54f61b6c5b764bdeac52d5371b77ed3802a7e68f",
"",
"reply"
],
[
"p",
"b907aa0bc5d09107b3070e8b392e2bd310cc538c34c3cbd86a76fb059b2cd073"
],
[
"proxy",
"https://social.treehouse.systems/users/marcan/statuses/112819461487847041",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://social.treehouse.systems/users/marcan/statuses/112819461487847041",
"pink.momostr"
],
[
"-"
]
],
"content": "\u003e Sounds as argument against big kernel and in favor more isolated drivers, and against \"hyper-privileged\" software in general...\n\nWhich is what macOS did, and why this can't happen on the macOS version of crowdstrike (it uses userspace drivers).\n\nLinux has similar mechanisms, but can't discourage kernel drivers by policy like macOS did since it's not as tightly controlled, so CrowdStrike on Linux still uses a kernel driver even though it could choose not to, because they suck.\n\n\u003e Kernel could unlock all mutexes on process death (and even if process leaked mutexes lock without crash), same way as file handles freed even if you use kill command on process....\n\nNo. If a mutex is locked then there is no guarantee that the data protected by it is in a consistent state. You can't just \"unlock all mutexes\", then you just get data corruption which is worse than the partial deadlocks. Mutexes are low-level constructs. The whole point/job of the kernel is to keep track of resources in a safe manner so this can be done for userspace handles like file descriptors. The buck stops somewhere and within the kernel it is impossible to do this because at the end of the day there has to be *some* code in charge of atomicity/consistency for resource state and *that* code itself cannot be freely interruptible.\n\n\u003e At userspace it resembles how nodejs domains used to intercept error to prevent ungraceful process crash.\n\n... and this works because Javascript is a high-level, memory-safe language. You can't do this with C.",
"sig": "ba40cd8ab40417ce8274467d43a547d162ccbb31e9d26802d88722b5f8f57709cd5cd4898a99163cc506c49ffd740281ffdcf93e0eb6d806f2b11243581c6745"
}