June 2023 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Missing Ubuntu tools on KernelBuild page
by Alan Perry June 3, 2023

June 3, 2023

Hi, I am trying out the kernel building instructions in https://kernelnewbies.org/KernelBuild with Ubuntu 20.04 and found missing/incomplete info. I would fix it myself but I only just got here and don't have access to do so. With regards to the "What tools do I need?" section, on Ubuntu, I found that I also needed to install flex, bison, and libefi-dev. Also, setting up the kernel configuration by duplicating my current config, there were broken paths to key files in the "Certificates for signature checking" section. Getting around that involves obtaining the files by installing linux-source and changing the paths to point to the appropriate files there. As I said, I am willing to make the changes to the wiki if given access to do so, but, if not, I hope that someone with access can make the changes. alan

1 0

eBPF Verifier's Design Principles
by Patrick ZHANG June 2, 2023

June 2, 2023

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

2 2

Running u-boot and linux on qemu arm64 virt machine, linux shell does not respond..
by Chan Kim June 2, 2023

June 2, 2023

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 0x40400000 0x44000000 0x40000000") ../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=0x40400000 -device loader,file=initrd.img,addr=0x44000000 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] tbnz w10, #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

1 0