4 ms·

qemu is a good way to experience with kernel hacking Hopefully someone can update the LDD(linux device driver) and Linux kernel books. In fact Linux Foundation

qemu is a good way to experience with kernel hacking Hopefully someone can update the LDD(linux device driver) and Linux kernel books. In fact Linux Foundation should sponsor such efforts since technical book like this is hard to make any profit.

deivid 2y ago
I've written a little bit about writing a driver & using QEMU to create a custom device for it at [0] & [1] [0]: https://blog.davidv.dev/posts/learning-pcie/ https://blog.davidv.dev/posts/learning-pcie/ [1]: https://blog.davidv.dev/posts/pcie-driver-dma/ https://blog.davidv.dev/posts/pcie-driver-dma/
- j33zusjuice 2y ago
  Are you the David V from Meta, who had bytelab.codes? I recently discovered that blog, and was very excited by the content, only to find he last updated in 2022. Either way, I’m excited to see your site, too! I love finding well-written kernel-level stuff.
  - troop 2y ago
    Did some digging (embarrassingly) and I don't think they are the same person. Regardless it's quite an interesting blog post!
commandersaki 2y ago
The wireguard test suite that’s now in the kernel is an excellent way to experiment with using qemu to develop kernel modules and also do automated tests. I’d link but cumbersome to find on phone.
- synergy20 2y ago
  do you mean this one: https://git.zx2c4.com/wireguard-linux/tree/tools/testing/selftests/wireguard https://git.zx2c4.com/wireguard-linux/tree/tools/testing/sel... there are only 3 files under drivers/net/wireguard/selftest and no qemu there in linux kernel git allowedips.c counter.c ratelimiter.c
  - commandersaki 2y ago
    Yes, but it's hard to find in the kernel: https://github.com/torvalds/linux/tree/5437f30d3458ad36e83ab96088d490ebfee844d8/tools/testing/selftests/wireguard https://github.com/torvalds/linux/tree/5437f30d3458ad36e83ab...
donaldihunter 2y ago
virtme-ng https://github.com/arighi/virtme-ng https://github.com/arighi/virtme-ng makes it really easy to launch development kernels in qemu.
znpy 2y ago
Greg KH said pretty explicitly there won’t be a 4th edition LDD
- j33zusjuice 2y ago
  Did he give any context for why? ROI for him, or?
  - sthuck 2y ago
    I'm purely guessing here, but also considering I read him and Linus both say "we have enough kernel developers", I think it's likely they don't want to encourage low quality contributions from new developers.
    - saagarjha 2y ago
      I wonder what a good way to help developers improve the quality of their contributions would be
    - mardifoufs 2y ago
      Wouldn't it be helpful then to put out more information on how to be a good contributor? I'm not sure how a technical book about the kernel would lead to worse contributions, you'd think a lack of readily available information and educational material would do that.
    - heavyset_go 2y ago
      Seems short-sighted. People retire, get new jobs, and move on from projects all the time.
iam-TJ 2y ago
I use qemu extensively especially for early-stage kernel debugging when no console is available; one such was just this week with v6.8 where, on arm64, any kernel command-line parameter >= 146 characters hangs the kernel instantly and silently. Here's how I used qemu + gdb (on Debian 12 Bookworm amd64 host) to emulate and execute the arm64 kernel build to single-step the problematic code to identify the cause. 1. In a prepared kernel build system (i.e; all build dependencies and cross-compile tools installed) build the kernel image. I do this in an unprivileged systemd-nspawn amd64 container to avoid messy -dev package installs on the host. Nspawn bind-mounts the host's source-code tree which includes a separate build directory: cd "${SRC_DIR}" # copy/install/configure a suitable ${BUILD_DIR}/.config; review/edit with: make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 4 menuconfig # build the kernel export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 12 Image # build gdb helper (Python) scripts export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} scripts_gdb This will create the debug symbols needed by gdb in ${BUILD_DIR}/vmlinux and the executable kernel in ${BUILD_DIR}/arch/arm64/boot/Image 2. Install "gdb" (and if doing foreign architecture debugging "gdb-multiarch") on the host as well as "qemu-system-arm" 3. Execute the kernel but -S[uspend] it and have QEMU listen for a connection from gdb: qemu-system-aarch64 -machine virt,gic-version=3 -cpu max,pauth-impdef=on -smp 2 -m 4096 -nographic -kernel ${BUILD_DIR}/arch/arm64/boot/Image -append "debug $( for l in {144..157}; do echo -n param$l=$(pwgen $((l-9)) 1)' '; done )" -initrd rootfs/boot/initrd.img-6.8.12-arm64-debug -S -gdb tcp::1234 The -append and -initrd shown here are optional; in my case no -initrd is actually needed since the (silent) panic occurs in the first few instructions the kernel executes. If debugging loadable modules however they would be in the initrd and loaded in the usual way. If the problem being diagnosed occurs after the root file-system and userspace proper are active then one would need to add the appropriate qemu options for the emulated storage device where the root file-system lives. 4. In another terminal shell (I use "tmux" and create a new tmux window) start the debugger: cd ${BUILD_DIR} # this cd is important - gdb needs to be in the base of the BUILD directory gdb-multiarch ./vmlinux 5. In the gdb shell: target remote :1234 break __parse_cmdline continue At this point the usual gdb functionality is available to examine memory, variables, single-step, view the stack and so on. For more details on debugging kernel using gdb and the gdb scripts lx-* see https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-debugging.html https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-... Edit: Forgot to note that for gdb to be able to use the lx-* Python scripts it usually needs the path authorising: echo "add-auto-load-safe-path ${SRC_DIR}/scripts/gdb/vmlinux-gdb.py" > ~/.gdbinit

deivid 2y ago

I've written a little bit about writing a driver & using QEMU to create a custom device for it at [0] & [1] [0]: https://blog.davidv.dev/posts/learning-pcie/ https://blog.davidv.dev/posts/learning-pcie/ [1]: https://blog.davidv.dev/posts/pcie-driver-dma/ https://blog.davidv.dev/posts/pcie-driver-dma/

j33zusjuice 2y ago
Are you the David V from Meta, who had bytelab.codes? I recently discovered that blog, and was very excited by the content, only to find he last updated in 2022. Either way, I’m excited to see your site, too! I love finding well-written kernel-level stuff.
- troop 2y ago
  Did some digging (embarrassingly) and I don't think they are the same person. Regardless it's quite an interesting blog post!

commandersaki 2y ago

The wireguard test suite that’s now in the kernel is an excellent way to experiment with using qemu to develop kernel modules and also do automated tests. I’d link but cumbersome to find on phone.

synergy20 2y ago
do you mean this one: https://git.zx2c4.com/wireguard-linux/tree/tools/testing/selftests/wireguard https://git.zx2c4.com/wireguard-linux/tree/tools/testing/sel... there are only 3 files under drivers/net/wireguard/selftest and no qemu there in linux kernel git allowedips.c counter.c ratelimiter.c
- commandersaki 2y ago
  Yes, but it's hard to find in the kernel: https://github.com/torvalds/linux/tree/5437f30d3458ad36e83ab96088d490ebfee844d8/tools/testing/selftests/wireguard https://github.com/torvalds/linux/tree/5437f30d3458ad36e83ab...

donaldihunter 2y ago

virtme-ng https://github.com/arighi/virtme-ng https://github.com/arighi/virtme-ng makes it really easy to launch development kernels in qemu.

znpy 2y ago

Greg KH said pretty explicitly there won’t be a 4th edition LDD

j33zusjuice 2y ago
Did he give any context for why? ROI for him, or?
- sthuck 2y ago
  I'm purely guessing here, but also considering I read him and Linus both say "we have enough kernel developers", I think it's likely they don't want to encourage low quality contributions from new developers.
  - saagarjha 2y ago
    I wonder what a good way to help developers improve the quality of their contributions would be
  - mardifoufs 2y ago
    Wouldn't it be helpful then to put out more information on how to be a good contributor? I'm not sure how a technical book about the kernel would lead to worse contributions, you'd think a lack of readily available information and educational material would do that.
  - heavyset_go 2y ago
    Seems short-sighted. People retire, get new jobs, and move on from projects all the time.

iam-TJ 2y ago

I use qemu extensively especially for early-stage kernel debugging when no console is available; one such was just this week with v6.8 where, on arm64, any kernel command-line parameter >= 146 characters hangs the kernel instantly and silently. Here's how I used qemu + gdb (on Debian 12 Bookworm amd64 host) to emulate and execute the arm64 kernel build to single-step the problematic code to identify the cause. 1. In a prepared kernel build system (i.e; all build dependencies and cross-compile tools installed) build the kernel image. I do this in an unprivileged systemd-nspawn amd64 container to avoid messy -dev package installs on the host. Nspawn bind-mounts the host's source-code tree which includes a separate build directory: cd "${SRC_DIR}" # copy/install/configure a suitable ${BUILD_DIR}/.config; review/edit with: make V=1 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 4 menuconfig # build the kernel export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} -j 12 Image # build gdb helper (Python) scripts export KBUILD_BUILD_USER=linux; export KBUILD_BUILD_HOST=iam.tj; time make V=1 LOCALVERSION="" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=${BUILD_DIR} scripts_gdb This will create the debug symbols needed by gdb in ${BUILD_DIR}/vmlinux and the executable kernel in ${BUILD_DIR}/arch/arm64/boot/Image 2. Install "gdb" (and if doing foreign architecture debugging "gdb-multiarch") on the host as well as "qemu-system-arm" 3. Execute the kernel but -S[uspend] it and have QEMU listen for a connection from gdb: qemu-system-aarch64 -machine virt,gic-version=3 -cpu max,pauth-impdef=on -smp 2 -m 4096 -nographic -kernel ${BUILD_DIR}/arch/arm64/boot/Image -append "debug $( for l in {144..157}; do echo -n param$l=$(pwgen $((l-9)) 1)' '; done )" -initrd rootfs/boot/initrd.img-6.8.12-arm64-debug -S -gdb tcp::1234 The -append and -initrd shown here are optional; in my case no -initrd is actually needed since the (silent) panic occurs in the first few instructions the kernel executes. If debugging loadable modules however they would be in the initrd and loaded in the usual way. If the problem being diagnosed occurs after the root file-system and userspace proper are active then one would need to add the appropriate qemu options for the emulated storage device where the root file-system lives. 4. In another terminal shell (I use "tmux" and create a new tmux window) start the debugger: cd ${BUILD_DIR} # this cd is important - gdb needs to be in the base of the BUILD directory gdb-multiarch ./vmlinux 5. In the gdb shell: target remote :1234 break __parse_cmdline continue At this point the usual gdb functionality is available to examine memory, variables, single-step, view the stack and so on. For more details on debugging kernel using gdb and the gdb scripts lx-* see https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-debugging.html https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-... Edit: Forgot to note that for gdb to be able to use the lx-* Python scripts it usually needs the path authorising: echo "add-auto-load-safe-path ${SRC_DIR}/scripts/gdb/vmlinux-gdb.py" > ~/.gdbinit