Re: eBPF Verifier's Design Principles
Hi Andrea, Thank you for your reply, and I appreciate you mentioning the Google article. After reading it, I noticed that the author did not clearly state the principles but only provided a few examples in the third paragraph. However, the article gave me the idea that I could sort and classify all vulnerability types of verifier-related CVEs. While this is only a proof and it is difficult to say that these types are corresponding to the verifier's design principle, it is a step forward. Thank you again for your help. Best regards, Patrick Andrea Tomassetti 于2023年6月1日周四 20:41写道： > > 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 > 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@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond..
Hello all, I'm trying to run u-boot and linux on qemu arm64 virt machine preferably without changing any source code. (u-boot v2022.07, linux 5.15.68, qemu 6.2.0, busybox 1.32.1) I have built u-boot using qemu_arm64_defconfig and I got u-boot(elf) and u-boot.bin. I built linux using defconfig but later I removed many CONFIG_* to reduce compile time and got Image(binary). Also, I built busybox and made ramdisk. Now this is the qemu command I used. (I referenced u-boot's include/configs/qemu-arm.h to determine the load addresses, set CONFIG_BOOTCOMMAND=" booti 0x4040 0x4400 0x4000") ../temp/qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic-version=max,secure=on,virtualization=true -cpu max -m 4G -nographic -bios u-boot/u-boot.bin -device loader,file=../temp/linux-5.15.68/arch/arm64/boot/Image,addr=0x4040 -device loader,file=initrd.img,addr=0x4400 u-boot runs and automatically boots linunx and it boots OK to the shell prompt. But at the linux shell prompt, it doesn't respond to my keyboard input. It looks like the symptom I saw last year when system counter is not working(for real board only). (I added system counter device in our qemu virtual machine just to not cause panic during the system counter access with the same driver. The qemu machine for our board runs ok using u-boot-spl and linux after booting including shell program and simple driver test. I'm trying to use u-boot proper now). Also last year I had to power-on the GICR(for virtual machine and real board). So I tried adding the code to power up GICR but it is the same. (this part is missing in u-boot, but I saw it is in the arm-tf S/W). For your reference this is the change in u-boot's arch/arm/lib/gic_64.S. /* x9: ReDistributor Base Address of Current CPU */ 2: mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb ==> /* x9: ReDistributor Base Address of Current CPU */ 2: // gicr power on, ckim mov w10, 2 str w10, [x9, GICR_PWRR] 5: ldr w10, [x9, GICR_PWRR] tbnzw10, #1, 5b /* Wait Children be Alive */ mov w10, #~0x2 ldr w11, [x9, GICR_WAKER] and w11, w11, w10 /* Clear ProcessorSleep */ str w11, [x9, GICR_WAKER] dsb st isb Can anyone suggest what I can try to solve this problem? (I mean, the problem of linux shell not responding in qemu virtual machine) I would appreciate it for any comment or help. Thank you. Chan Kim ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
