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
eBPF Verifier's Design Principles
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
Re: Kernelnewbies Digest, Vol 142, Issue 6
Hi Philipp Thanks for the great intro on how to write & submit a Linux kernel patch. I’m very interested in it! I’m busy this week but I will start working on the driver cleanup next week. Looking forward to the experience of submitting my first kernel patch! Best, Patrick > On 18 Sep 2022, at 18:00, kernelnewbies-requ...@kernelnewbies.org > <mailto:kernelnewbies-requ...@kernelnewbies.org> wrote: > > Send Kernelnewbies mailing list submissions to > kernelnewbies@kernelnewbies.org <mailto:kernelnewbies@kernelnewbies.org> > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > <https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies> > or, via email, send a message with subject or body 'help' to > kernelnewbies-requ...@kernelnewbies.org > <mailto:kernelnewbies-requ...@kernelnewbies.org> > > You can reach the person managing the list at > kernelnewbies-ow...@kernelnewbies.org > <mailto:kernelnewbies-ow...@kernelnewbies.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. Re: Get personal support for your first kernel patch > (Philipp Hortmann) > > > -- > > Message: 1 > Date: Sun, 18 Sep 2022 09:08:15 +0200 > From: Philipp Hortmann <mailto:philipp.g.hortm...@gmail.com>> > To: kernelnewbies@kernelnewbies.org <mailto:kernelnewbies@kernelnewbies.org> > Subject: Re: Get personal support for your first kernel patch > Message-ID: <22b8a153-d34e-af62-c8a4-ef1bbe820...@gmail.com > <mailto:22b8a153-d34e-af62-c8a4-ef1bbe820...@gmail.com>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > you can follow the description on this homepage: > https://kernelnewbies.org/FirstKernelPatch > <https://kernelnewbies.org/FirstKernelPatch> > I learned from this document. > > That has some issues because it is not updated in all points but it > works. I cannot update because I do not have the permission. > > Here the hints I wand to give you: > > Do not use: > apt-get install python-ply python-git > Use: > apt-get install python3-ply python3-git > > When you use gmail with mutt: > - activate dual factor authentication > - use "app password" for mutt > That is working fine. > > > I also like to recommend the following youtube videos: > "Write and Submit your first Linux kernel Patch" by Greg Kroah-Hartman - > 12 years old but still very valid. > > Best entertainment about things went wrong with patches: > LCA13: Keynote Greg Kroah-Hartman "I don't want your code" > > > Bye Philipp > > > > -- > > Subject: Digest Footer > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org <mailto:Kernelnewbies@kernelnewbies.org> > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > <https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies> > > > -- > > End of Kernelnewbies Digest, Vol 142, Issue 6 > * ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question regarding clock-provider and m41t80.c
Hi everyone,
I recently went mainline with our embedded device and so far I am happy that
I've done it. Coming from a quite old kernel (4.1.15) there are some new
features and changes I need to get my head around and one is bugging me for
quite some time now.
We are using an RTC which depends on the m41t80 kernel driver. This RTC has a
CLK-OUT feature which is per default to ON and 32kHz. We have another chip
wired and depending to that clock signal.
On kernel version 4.1.15 there was no feature to enable/disable square wave
output for this rtc driver, so it was always on per default.
In newer kernel versions is a change which is adding clock-provider feature to
use and enable/disable that CLK-OUT feature.
Which results in the clock output signal being turned of as default option. Now
I am totally lost on how to activate that feature in - I think the device tree?
I read through all documentation regarding the matter and tried adding clock
attributes in the dts but with no luck so far. My entry is:
/* external real time clock */
i2c_rtc: rtc@68 {
pinctrl-names = "default";
pinctrl-0 = <_rtc_int>;
compatible = "st,rv4162", "fixed-clock", "microcrystal,rv4162";
reg = <0x68>;
interrupt-parent = <>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
status = "okay";
#clock-cells = <1>;
clock-frequency = <32678>;
clock-output-names = "rtcosc";
};
Any help is appreciated!
Best regards,
Patrick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
On Tue, Mar 8, 2016 at 11:03 AM, 张云 <zyun...@163.com> wrote: > > You can circumvent the grub-install bug by substituting a USB memory for > the disk image. > > 发自 网易邮箱大师 <http://u.163.com/signature> > Ok, thanks! -Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
> > The problem is caused by the command below > > mkfs -t vfat /dev/loop0 > > > /dev/loop0 is the whole disk, and /dev/loop0p1 is the partition. > > The command make a file system on the disk, thus overrides the disk’s > partition table. > > I guess that it is the partition on which you want to make a filesystem. > The right command is > > mkfs -t ext2 /dev/loop0p1 > > We prefer ext2,3,4 to fat32 on linux. > > I see. Thanks! I used kpartx to map the partitions in /dev/mapper. If you know of a better way of doing what you suggest, could you please let me know? I was hoping to use ext4, but I wasn't able to grub-install to a loopback device. When I try to, I get the error: > grub-install: error: disk `lvm/loop1p1' not found. From a searching around, it looks like this issue has been visited recently by the developers: https://lists.gnu.org/archive/html/grub-devel/2015-05/msg00011.html So I wasn't able to get it to work. So instead I've been using syslinux, which I believe requires FAT, rather than EXT. I read about extlinux, but from my reading, I've gotten the impression that syslinux has more history. So I figured it would be easier to find useful material for syslinux on message boards. Thanks again for all your help! I hope that at some point I'll be able to do more, such as customize the ram disk, the init system, and figure out how to get the system switched over to a root file system on a disk. -Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
On Fri, Mar 4, 2016 at 9:09 PM, 张云 <zyun...@163.com> wrote: > First your must know exactly how linux boot (not at source code level). > > Most recent linux distributions boot as > > grub —> kernel —> initramfs’ /init executable > > All the userspace affair is started by initramfs’ /init. Kernel no longer > join the boot process. > > From you description, I think you were blocked by the initramfs concept. > Initramfs is the first root filesystem and reside in memeory. > It’s loaded by grub, and the kernel automatically mount it, execute the > /init. The /init executable can do some extra initialisation > and switch to the real root filesystem on disk. > for detail /Documentaion/filesystems/ramfs-rootfs-initramfs > > Hope that would be useful to your. > Thanks for the response. I was able to get a minimal boot using the files in the mini.iso image from Ubuntu. I just copied the kernel and the ramdisk image from that iso, and these have given me enough to start learning some things. It is still just dropping me into the prompt for the ramdisk image, so the kernel hasn't yet made the switch over to root filesystem on a drive, but this is at least enough to get me started. One thing I noticed that confused me was the result of the commands pasted below. It looks like the partition table on the disk image might be getting messed up. But, interestingly enough, it still seems to allow me to use the image for booting. In spite of this, fdisk is giving me strange output when I ask it to print out the partition tables after I build a file system on the disk image using mkfs. When I look at the disk image using gparted, on the other hand, it actually looks OK. It looks like I might be using mkfs incorrectly. Can anyone see anything obvious that I am doing wrong? == dd if=/dev/zero of=./disk.img bs=1M count=1000 sudo losetup /dev/loop0 ./disk.img sudo fdisk /dev/loop0 (commands in fdisk) > n (new partition) > p (primary partition) > 1 (partition number) > (default start and end for partition) > t (change type of partition) > b (change type of partition to FAT32) > a (set boot flag) > 1 (set boot flag for first partition) > w (write changes) fdisk -lu /dev/loop0 Disk /dev/loop0 : 1048 MB, 1048576000 bytes 123 heads, 59 sectors/track, 282 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x7b9351bf Device Boot Start End Blocks Id System /dev/loop 0 p1 *2048 2047999 1022976b W95 FAT32 mkfs -t vfat /dev/loop0 fdisk -lu /dev/loop0 Disk /dev/loop0: 1048 MB, 1048576000 bytes 255 heads, 63 sectors/track, 127 cylinders, total 2048000 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System == Thanks, Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
> > What filesystem is on the /dev/sda image that qemu is using? You'll need > to > > > either build your kernel with the support for that built into the kernel, > or an initrd that modprobes the filesystem module, and then mounts the > filesystem (then there's a few fun and games involved in pivoting from > the ram filesystem the initrd is using as root, to the disk image > filesystem > that you want as the root filesystem after boot). > Thanks for the response. This is helpful. I copied the vmlinuz and initrd image from my host, and that seemed to get me further. Now blkid says: /dev/sda: SEC_TYPE="msdos" UUID="6815-7325" TYPE="vfat" The mount command indicates that it mounted successfully at /root. The contents of /root are just: vmlinuz syslinux.cfg initrd.img ldlinux.c32 ldlinux.sys I realize that isn't enough to get the system up, so I would like to try to figure out what I need to drop in there to get the system going. I think that the other responses that people have so kindly sent to my question might help me further, since they talk about init. Although I copied vmlinuz and initrd from the host to get this far, I hope to eventually figure out how to do something less hacky. I am able to build the kernel, but I don't really know what's involved with building initrd for the guest. (It seems I was able to build one on the host using initramfs, but I'd like to figure out how to build one for the host. I'd also like to better understand the "fun and games" you were talking about with pivoting from the ram filesystem to the disk image filesystem. ...but I'll take it one step at a time, I guess.) By the way, I'm a double alum (BS and MS) from VT. Go Hokies! Thanks again, Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
On Fri, Mar 4, 2016 at 3:56 PM, Kristof Provost <kris...@sigsegv.be> wrote: > > On 04 Mar 2016, at 23:50, Patrick <plafr...@gmail.com> wrote: > Thanks for the response. I had seen that StackOverflow post and done > that a couple of days ago. I was hoping there was another answer, since I > wouldn't be able to do that if I weren't using QEMU. > > If you weren’t using Qemu I’d point you at netconsole. The first step in > debugging panics is always to figure out what the panic is. > > When I looked at the output from QEMU a couple of days ago, the kernel was > saying that it couldn't find a device to mount with the root filesystem. So > I generated an initrd image on the host Linux system, and I used that on > the guest which got me to a BusyBox prompt. But this was totally a hack, > since I didn't even know if getting an initrd image was really the next > thing I needed to do. I was hoping someone might be able to point me to > something that might explain what to do to get the kernel to mount a device > with the root filesystem. > > You want to pass the ‘root=/dev/foo’ option to your kernel. Obviously > change /dev/foo into whatever device you’re booting from. > > Regards, > Kristof > Ok, thanks. I will try to look into netconsole. I had tried changing the "root" option. I had noticed that the QEMU output showed the kernel printing out this: [4.312088] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [4.322029] Please append a correct "root=" boot option; here are the available partitions: [4.327850] 0100 65536 ram0 (driver?) [4.337399] 0101 65536 ram1 (driver?) [4.345170] 0102 65536 ram2 (driver?) [4.345691] 0103 65536 ram3 (driver?) [4.346251] 0104 65536 ram4 (driver?) [4.346825] 0105 65536 ram5 (driver?) [4.347442] 0106 65536 ram6 (driver?) [4.350055] 010a 65536 ram10 (driver?) [4.352624] 010b 65536 ram11 (driver?) [4.353597] 010c 65536 ram12 (driver?) [4.354517] 010d 65536 ram13 (driver?) [4.354977] 010e 65536 ram14 (driver?) [4.358393] 010f 65536 ram15 (driver?) [4.359420] 0b00 1048575 sr0 driver: sr [4.360499] 0800 102400 sda driver: sd [4.367898] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) I hadn't noticed "sda" before. So I tried pointing root at this. Then I got this: [4.375721] List of all partitions: [4.383491] 0100 65536 ram0 (driver?) [4.386418] 0101 65536 ram1 (driver?) [4.388736] 0102 65536 ram2 (driver?) [4.390931] 0103 65536 ram3 (driver?) [4.391266] 0104 65536 ram4 (driver?) [4.391726] 0105 65536 ram5 (driver?) [4.392812] 0106 65536 ram6 (driver?) [4.393340] 0107 65536 ram7 (driver?) [4.393932] 0108 65536 ram8 (driver?) [4.394906] 0109 65536 ram9 (driver?) [4.396283] 010a 65536 ram10 (driver?) [4.399212] 010b 65536 ram11 (driver?) [4.400067] 010c 65536 ram12 (driver?) [4.401832] 010d 65536 ram13 (driver?) [4.402775] 010e 65536 ram14 (driver?) [4.403572] 010f 65536 ram15 (driver?) [4.404046] 0800 102400 sda driver: sd [4.412148] 0b00 1048575 sr0 driver: sr [4.413323] No filesystem could mount root, tried: ext3 ext2 ext4 vfat fuseblk [4.415310] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,0) So, I think maybe now the kernel is missing some things it needs on /dev/sda. Right now, I don't think there is anything on it other than the bootloader. Do you happen to know where I can find what the kernel needs to proceed? Thanks, Patrick > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Booting with SYSLINUX on Loopback Device: Kernel Panic - Where to Start?
Hello, I was able to install SYSLINUX on a disk image and get the kernel I built to start booting Linux with QEMU pointing to a loopback device associated with the disk image. However, at some point far into the boot process, I get a kernel panic. I can't read the beginning of the error messages that the kernel prints, because the errors run off the screen. I copied the bzImage onto the disk image, and I'm not sure where to go from there. Is the next step to build the initrd image? I don't yet know how to get the kernel to mount a device so it can find the root file system. Any help is appreciated. Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: eudyptula response time
does anyone have an idea when is the response time for task 08? When I submitted last december, I was 115th in the queue. I don't want to resubmit again fearing that I will be bumped up into the end. Dean I was also thinking about asking about my current queue-status (different task), but oh well. It would be a nice feature if automated. Anyways: you're not alone waiting ;) martin After asking something similar a few days ago, it was brought to light that responses will be slow for the moment. I'm quoting what Giedrius told me then: Taken from December 2014 challenge status report: But note, for everyone, responses for the next month are going to be very limited. So relax, go read a good book, take a bike ride, enjoy the lovely weather outside, don't worry about kernel programming challenges, they aren't going anywhere, and as this isn't costing you anything, there's nothing you can do about it. Also don't resubmit your solution because that will put you at the end of the queue. Thanks, Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Eudyptula Challenge Task 03 Queue Question
On Wed, 2015-01-28 at 19:03 -0500, Patrick Creech wrote: Hi! Just have a minor question on task 03's queue. I submitted my solution on 1-18-2015, and the queue status in the response was: .. number 23 in line, and the response that is next is from 14 Jan 2015 15:07:46 +0530 ... I resubmitted it yesterday due to no response, and the queue status was: ... number 53 in line, and the response that is next is from 14 Jan 2015 19:29:35 +0100 ... Just curious if this was normal or not. Thanks, Patrick Quick clarification, I'm not inquiring as to being re-queued, but to the fact that there has been minimal progress in the queue since the 14th of January. I apologize for the confusion ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Eudyptula Challenge Task 03 Queue Question
Hi! Just have a minor question on task 03's queue. I submitted my solution on 1-18-2015, and the queue status in the response was: .. number 23 in line, and the response that is next is from 14 Jan 2015 15:07:46 +0530 ... I resubmitted it yesterday due to no response, and the queue status was: ... number 53 in line, and the response that is next is from 14 Jan 2015 19:29:35 +0100 ... Just curious if this was normal or not. Thanks, Patrick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
When Are Free Pages Zeroed?
I'm looking into the Linux memory management subsystem and need to know when freed pages are zeroed. Specifically, are they zeroed just before they are reallocated, immediately after they are freed, or sometime in-between? Also, what files/functions would I need to modify to change this behavior? Thanks for any help and kindest regards, --Patrick -- If I'm not here, I've gone out to find myself. If I get back before I return, please keep me here. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
