4 ms·

However, it wouldn't be impossible. I am quite sure (although I don't have a proof) that the BPF bytecode can be made turing complete, so an arbitrary program (

However, it wouldn't be impossible. I am quite sure (although I don't have a proof) that the BPF bytecode can be made turing complete, so an arbitrary program (maybe a rootkit, much more likely patches to a few kernel structures) could be implemented in it. Examples of things that are very unintendedly turing complete include HTML5 without JS(the clicky rule 110), ELF relocations (you can write a program to be interpreted by the loader in a few symbols and relocations without changing code, see elf-bf-tools on GitHub) and the Intel interrupt handling mechanism(unreleased, see talk at 29c3). Furthermore, you don't need dynamically loadable modules in the kernel for kernel code injection, see http://www.phrack.org/issues.html?id=7&issue=58 http://www.phrack.org/issues.html?id=7&issue=58

haberman 14y ago
elf-bf-tools is an impressive hack, thanks for the link! To add to your list, you might want to mention that simply parsing C++ is turing-complete; see http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 http://yosefk.com/c++fqa/web-vs-c++.html#misfeature-3 . The short of it is that you have to perform full template instantiation in some cases just to parse code that uses those templates! As to your point about /dev/kmem, to me that is just another argument against the idea of banning JITs from the kernel. There are already lots of vectors for getting attack payloads into the kernel; the JIT angle only helps an attack if you somehow can make the kernel jump to a specified address but don't have root.