3 ms·

From the article: Buggy kernel code will crash your machine. The kernel is not protected from a buggy kernel module. I think people assumed that this is just h

From the article: Buggy kernel code will crash your machine. The kernel is not protected from a buggy kernel module. I think people assumed that this is just how things are; that's the price to do kernel programming. eBPF changed this dogma. It brought safety to kernel programming. "It brought safety to kernel programming" , if you use eBPF and don't expose bugs in the parser, or checking or validation systems. (These have already happened).

tptacek 6y ago
He means security in the sense of adding new security controls to Linux. Yes, the core idea of BPF (e- or otherwise) is that the code can be verified not to harm the kernel.
tgraf 6y ago
Extending a bit on what Alexei is talking about (Full eBPF summit talk: https://youtu.be/jw8tEPP6jwQ?t=639 https://youtu.be/jw8tEPP6jwQ?t=639) Many people seem to make an assumption that kernel code is perfect and that when code is merged into the Linux kernel, it is automatically secure. That is definitely not the case. Kernel developers make mistakes as well and they have devastating consequences. Right now, the security of the Linux kernel code depends on a combination of code review, fuzzing, controlling the pace of code changes, and running LTS releases to increase the chance others found the bugs already. eBPF further increases the security model of kernel development by adding a verification step to the model. It means that there is an additional layer of protection in case of code imperfections. The focus on eBPF safety is awesome. eBPF is software, software will have bugs, eBPF is no exception. The best way to improve the security of software is to question it. Given the wide spread use of eBPF in highly critical and exposed scenarios, the pressure on making it as bug-free as possible is very high so it's probably fair to assume that the scrutiny put in place, will lead to a high quality implementation of the verifier.
- tptacek 6y ago
  BPF has always been statically verified, back to 1991 or whenever. If anything, eBPF is less sound than classic BPF, because the verifier is dramatically more complicated, as is the execution environment.

tptacek 6y ago

He means security in the sense of adding new security controls to Linux. Yes, the core idea of BPF (e- or otherwise) is that the code can be verified not to harm the kernel.

tgraf 6y ago

Extending a bit on what Alexei is talking about (Full eBPF summit talk: https://youtu.be/jw8tEPP6jwQ?t=639 https://youtu.be/jw8tEPP6jwQ?t=639) Many people seem to make an assumption that kernel code is perfect and that when code is merged into the Linux kernel, it is automatically secure. That is definitely not the case. Kernel developers make mistakes as well and they have devastating consequences. Right now, the security of the Linux kernel code depends on a combination of code review, fuzzing, controlling the pace of code changes, and running LTS releases to increase the chance others found the bugs already. eBPF further increases the security model of kernel development by adding a verification step to the model. It means that there is an additional layer of protection in case of code imperfections. The focus on eBPF safety is awesome. eBPF is software, software will have bugs, eBPF is no exception. The best way to improve the security of software is to question it. Given the wide spread use of eBPF in highly critical and exposed scenarios, the pressure on making it as bug-free as possible is very high so it's probably fair to assume that the scrutiny put in place, will lead to a high quality implementation of the verifier.

tptacek 6y ago
BPF has always been statically verified, back to 1991 or whenever. If anything, eBPF is less sound than classic BPF, because the verifier is dramatically more complicated, as is the execution environment.