how is your work on KSPP these days?
Conversation
Replying to
I mostly stopped working on kernel hardening, especially submitting changes upstream, because I got tired of dealing with the toxic environment. I also increasingly feel Linux kernel security is a lost cause and I'm hopeful for a future with a microkernel + Linux compat layer.
1
1
2
The Linux kernel is the equivalent of running the entirety of userspace as root in PID 1. There's no isolation or internal security model. It keeps getting worse as more and more complexity is piled on, all of it implemented in C and without any isolation between components.
1
3
5
They've also introduced a very powerful bytecode interpreter / JIT compiler (eBPF) that's being increasingly used for different features.
I don't think the approach of piling on exploit mitigations to a project without safe tools (memory safe languages) and isolation can work.
1
Exploit mitigations should be a final line of defence to raise the cost of attacks, not the entire basis for security. The *nix security model has also aged poorly and the only way to get decent security policies for userspace is SELinux combined with various ad-hoc features.
1
I think the people trying to hold back the tide of insecurity in the Linux kernel are doing valuable work, but I prefer working on things that are actually workable and not doomed to fail. I think Linux kernel security is getting worse over time, despite hardening efforts.
1
Replying to
How do you view the progress in integrating grsec features? Is there still a lot to go?
1
Replying to
They made a fair bit of progress on that and on providing other mitigations but there's still a lot of catching up to do in various areas and that's just compared to the previous public patches. The efforts are also inconveniently split up between GCC and Clang-based work.
1
Clang / LLVM is going to be a better platform for this because it's much further along in implementing mitigations upstream. Academics / researchers generally target Clang. Google is also doing a large portion of the work and has moved to Clang for both kernel and userspace.
1
Clang has forward edge (indirect function calls) type-based Control Flow Integrity upstream along with SafeStack and Google ported both to the Linux kernel. The Pixel 3 kernel ships with CFI enabled.
It's at odds with the work of making assorted GCC plugins for hardening though.
1
They'll be making an implementation of CFI for protecting returns and there will be a lot of other compiler work. It's odd that the most important / difficult work is being done upstream for Clang and yet KSPP is still focusing on small improvements via downstream GCC plugins.
Google is only going to care about Clang since it's what they're using, and they're doing 90% of the work. GCC requires copyright assignment which drives away many contributors, including myself, as I won't contribute to a project requiring that. Many companies also hate GPLv3.