Linux kernel security is trending in the wrong direction. More complexity, more attack surface, more code churn.
-
-
One outcome of my taking on kernel work might be gaining enough experience to redo it right. :-)
1 reply 0 retweets 0 likes -
It really needs a many-pronged approach, and the Linux kernel is failing at every aspect of improving security.
1 reply 1 retweet 0 likes -
Replying to @CopperheadOS @RichFelker and
Moving more code into the kernel, instead of moving towards a microkernel like competing operating systems.
1 reply 0 retweets 1 like -
Replying to @CopperheadOS @RichFelker and
And sticking with using entirely C, instead of migrating towards a safe language for new / rewritten components.
3 replies 0 retweets 0 likes -
Replying to @stribika @RichFelker and
It's a lot more now. eBPF expanded it into something scarier and added use cases like profiling rules.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS @stribika and
Last I checked you could disable all that crap entirely at configure time, though.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @stribika and
Not as much can be disabled as you'd expect. It's not even possible to disable PERF_EVENTS on x86_64.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker and
AFAIK, eBPF is essentially mandatory. JIT compiler is disabled by default with sysctl toggle though.
1 reply 0 retweets 0 likes
NET selects BPF, but BPF_JIT is optional, not even present on all archs, and BPF_SYSCALL is optional
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.