6 ms·

It's not a mono culture but the idea of true cross-platform APIs that could make supporting BSD kernels much much easier in both terms of development time and i

It's not a mono culture but the idea of true cross-platform APIs that could make supporting BSD kernels much much easier in both terms of development time and interoperability. > I would prefer that we avoid monocultures. Where were you to say "Stop the C and POSIX monoculture", because that's a pretty opinionated view on how to build kernels, too, you know. I'd prefer interoperability over having to implement everything myself all the time, any day.

yjftsjthsd-h 3y ago
People do regularly point out that POSIX limits exploration of interesting ideas in computing, and a segment of the community is actively attempting to deprecate C. I think it's a continuum; I personally think being unix-like is a useful baseline without being too limiting, but the cost/benefit rapidly degrades after that. As a topical example, I'm glad that everything didn't adopt iptables, because pf seems to be more friendly to work with. I don't mind ebpf, but I wouldn't be surprised to see one of the BSDs leapfrog it.
- cookiengineer 3y ago
  My point of view is always a little too much security focussed when it comes to kernel mod dev. I completely agree with embracing Rust and other memory safe languages. Hence why I think eBPF has huge potential due to their CORE abstractions that are very strict in terms of memory management and validation. But when the source code of the NSA's ebpf malware was leaked, I got concerned because currently there is no failsafe way to audit a running kernel. I think that the logical conclusion to this has to be something like a manifest file for each running kernel module, and a better feature-based sandbox for each module that is running or hooked (e.g. usb, network, filesystem, home folder etc). Similar to how Android's sandboxes are designed, but with a concept that is able to sandbox kernel mods, too. Seccomp sandboxes are not enough, and there is gonna be a decade of new ebpf malware ahead of us. I wish that rust got more traction, because that would at least solve all the pointer corruptions and overflows that can/are going wrong in module codebases.

yjftsjthsd-h 3y ago

People do regularly point out that POSIX limits exploration of interesting ideas in computing, and a segment of the community is actively attempting to deprecate C. I think it's a continuum; I personally think being unix-like is a useful baseline without being too limiting, but the cost/benefit rapidly degrades after that. As a topical example, I'm glad that everything didn't adopt iptables, because pf seems to be more friendly to work with. I don't mind ebpf, but I wouldn't be surprised to see one of the BSDs leapfrog it.

cookiengineer 3y ago
My point of view is always a little too much security focussed when it comes to kernel mod dev. I completely agree with embracing Rust and other memory safe languages. Hence why I think eBPF has huge potential due to their CORE abstractions that are very strict in terms of memory management and validation. But when the source code of the NSA's ebpf malware was leaked, I got concerned because currently there is no failsafe way to audit a running kernel. I think that the logical conclusion to this has to be something like a manifest file for each running kernel module, and a better feature-based sandbox for each module that is running or hooked (e.g. usb, network, filesystem, home folder etc). Similar to how Android's sandboxes are designed, but with a concept that is able to sandbox kernel mods, too. Seccomp sandboxes are not enough, and there is gonna be a decade of new ebpf malware ahead of us. I wish that rust got more traction, because that would at least solve all the pointer corruptions and overflows that can/are going wrong in module codebases.