Hi Patrick, there's a lot of work related to security and exploiting the eBPF verifier out there. I'm not an expert myself, but the principles you exposed seem right. Here there's a nice and recent article about eBPF fuzzing: https://security.googleblog.com/2023/05/introducing-new-way-to-buzz-for-ebpf.html Best, Andrea On Thu, Jun 1, 2023 at 9:48 AM Patrick ZHANG <patrickzhang2333@xxxxxxxxx> wrote: > > Hi there, > I am not sure I am doing this in the right way. > I writing to seek your guidance and expertise regarding on kernel security. > Specifically, my focus has been on the eBPF environment and its verifier, > which plays a crucial role in ensuring kernel safety. > > While conducting my research, I discovered that there are no official > documents available that outline the principles of the verifier. > Consequently, I have endeavored to deduce the kernel safety principles > ensured by the verifier by studying its code. Based on my analysis, I > have identified the following principles: > 1. Control Flow Integrity: It came to my attention that the verifier > rejects BPF programs containing indirect call instructions (callx). By > disallowing indirect control flow, the verifier ensures the identification > of all branch targets, thereby upholding control flow integrity (CFI). > > 2. Memory Safety: BPF programs are restricted to accessing predefined > data, including the stack, maps, and the context. The verifier effectively > prevents out-of-bounds access and modifies memory access to thwart > Spectre attacks, thus promoting memory safety. > > 3. Prevention of Information Leak: Through a comprehensive analysis of > all register types, the verifier prohibits the writing of pointer-type > registers > into maps. This preventive measure restricts user processes from reading > kernel pointers, thereby mitigating the risk of information leaks. > > 4. Prevention of Denial-of-Service (DoS): The verifier guarantees the > absence of deadlocks and crashes (e.g., division by zero), while also > imposing a limit on the execution time of BPF programs (up to 1M > instructions). These measures effectively prevent DoS attacks. > > I would greatly appreciate it if someone could review the aforementioned > principles to ensure their accuracy and comprehensiveness. If there are > any additional principles that I may have overlooked, I would be grateful > for your insights on this matter. > > Furthermore, I would like to explore why the static verifier was chosen as > the means to guarantee kernel security when there are other sandboxing > techniques that can achieve kernel safety by careful design. > > The possible reasons I can think of are that verified (and jitted) BPF > programs can run at nearly native speed, and that eBPF inherits the verifier > from cBPF for compatibility reasons. > > Thank you very much for your time and attention. I appreciate the feedback > and insights. > > Best, > Patrick > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
