Yes. [1] I also understand its limitations, e.g. not being able to do DNS compression due to its linearity and the bpf verifier only allowing statically inlined helper functions etc.
I think in general there is a misconception about what I was talking about. Maybe I was too unclear, dunno. I am aware that kernel self-checks cannot be implemented in the kernel itself. That is what I wanted to point out in my previous comment.
I was always talking about whether or not it's possible to protect the kernel from receiving known malicious network packets that could cause an RCE. And I think it is possible.
It's not just "you can't do DNS compression", or "you probably can't do general-case string comparisons". It's much more fundamentally that anything you "detect" in eBPF code, even in the extremely rare cases where it's offloaded into NIC chipset, has to get plugged right back into the kernel to do anything with that data. You can't write a general-purpose eBPF program; eBPF is just an telemetry and packet processing offload.
That eBPF firewall is a perfect example of what I'm talking about. It relies not just on the kernel but on a cooperating userland process to do all the "interesting" bits.
Yes. [1] I also understand its limitations, e.g. not being able to do DNS compression due to its linearity and the bpf verifier only allowing statically inlined helper functions etc.
I think in general there is a misconception about what I was talking about. Maybe I was too unclear, dunno. I am aware that kernel self-checks cannot be implemented in the kernel itself. That is what I wanted to point out in my previous comment.
I was always talking about whether or not it's possible to protect the kernel from receiving known malicious network packets that could cause an RCE. And I think it is possible.
[1] https://github.com/tholian-network/firewall/blob/master/ebpf...