Now that we've got our kernel dev environment setup, it's time to get stuck in! I'll briefly touch on generating patches, because why not, and instrumentation (though I'm not as familiar with this topic) before finally covering how we can debug kernel modules. if you don't need to worry about module signing/taint, and you're happy to get messy, there's hackier ways to do all this too.you may be able to fetch source from your distro repos, where you can then patch and build modules from there.if you just want to do some debugging, you could pull debug symbols from your distribution repo (see section on symbols below).Skip Building Altogetherĭepending on your requirements, you can just avoid building altogether: So to speed things up dramatically, if you're familiar with the module(s) you're going to be looking at, a more efficient approach is to start from a minimal config and enable the bare minimum features required for your testing environment.įor example $ make defconfig will generate a minimal default config for your arch, and then you can use $ make menuconfig to make further adjustments. Shortcuts & AlternativesĪs some of you may already be painfully aware, building a full-featured kernel can actually take some time, especially in a VM with limited resources. I'm then able to go ahead and re/load tipc and we're good to go! Easy as that. For example, for CVE-2022-0435 I tested a patches in net/tipc/monitor.c, so to rebuild and install my patched module I'd simply run: $ make M=net/tipc Instead, we can make whatever changes we intend to make to our module and then run much the same commands we did during the initial install, only targeting our patched module(s). ![]() ![]() While the initial build can be lengthy, it's straightforward and we avoid the headache of out-of-tree module taints, signing issues and other finicky version-mismatch related issues. ![]() Okay, now we have a clean environment to work with and can start tinkering! Because we've built the kernel from source, we know we're building our patched modules in the exact same development environment as the kernel we're installing them into. So, to install our modules we'll go ahead and run: $ sudo make modules_installįinally we'll install the kernel itself the follow command will do all the housekeeping required to let us select the new kernel from our bootloader: $ sudo make installĪnd voila! Just like that we've built our Linux kernel from source, nabbing the config from our current environment, and we're ready to do some tinkering! Module Patching The only real hard requirement I assume, is that you're doing your kernel stuff in a VM as this'll make debugging the kernel a lot easier down the line. This basically just means setting up an Ubuntu VM (representative of a typical in-the-wild box) with a vulnerable kernel version. When finding a vuln, or looking into an existing bug, I'll want to set up a representative environment to play around with it. This post is written in the context of kernel security research, which might deviate from other use cases, so bear that in mind when reading this post. This post ended up being quite long, so if you like a narrative and hearing the why behind the how, please continue! But for brevity I've also included the essentials my repo over at sam4k/linux-kernel-resources.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |