OK, so I think I've taken this personal project of mine to see how much I could trim down the dom0 kernel as far as I can on my own (or rather, I've found a set of settings that work for the hardware I own, but I'm not sure how it'll perform on other people's hardware) so I'm ready to share the results of my work.
This is what I've managed to slim down/disable and still have a working dom0: - Disabled the vast majority of options under "Networking Support" including Bluetooth (I had to leave TCP/IP support enabled as libvirt needs it to create sockets; because of that, I left SYN cookie and Security Marking enabled in case it uses it, but if it doesn't, those two options could also be disabled and things would still work). - All hardware networking driver support (including Wireless); dom0 shouldn't have access to the network because it's all done through a NetVM; hence that driver support no longer needs to be in dom0. - Various hardware drivers (Legacy stuff like PCMCIA, ISDN, Floppy Disks, plus Dallas 1-wire support (was on the fence on that one), stuff regarding fibre channel support and other things that Qubes would be unlikely to run on, although it's theoretically possible that it could be). - Slimmed down on some of the Security options, taking out Apparmor (it never worked in Fedora dom0 anyways) and SELinux support (if you really use it in dom0, you could compile it back in yourself). - Implemented most of the KSPP's recommended options here: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project All-in-all, around 3,000 various kernel options were disabled, although you could theoretically take that further by stripping out support for hardware you don't use, and I'd love to do the same sorts of things to some of the other sections like Cryptographic Support. That said, the hardware support was something I struggled with. The Networking stuff was easy; that's all handled by a NetVM so it could all go. And if you have a USBVM, then it's easy: Disable all USB hardware support except keyboard, mouse and touchscreen. However, for the moment, there's no guarantee that every Qubes OS user runs a sys-usb VM (for various reasons, many probably valid) so I left all of that support in. On my personal kernel, however, I did disable all of that and leave it to a sys-usb VM to sort out, but my USB hardware needs are minimal; yours may not be. And ditto if you use the PCI pass-through functionality. And there's also a near-infinite variety of hardware configurations out there that Qubes could theoretically run on too, some of them really obscure, so it was difficult for me to figure out what to cut and what to keep/add in. So this is where the Qubes community can help. I've posted my slim kernel branch, based on 4.9 here: https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.9-slim And a somewhat stock 4.9 kernel branch here: https://github.com/rtiangha/qubes-linux-kernel/tree/stable-4.9 And I'd like people to try both and offer some feedback on it. Is there stuff that used to work on the full 4.9 kernel or older kernels that doesn't work with the slim version? If so, let me know what it is and I'll add that support back in. Do people run Qubes on obscure hardware or unique/different hardware combinations that no longer works on the slim kernel (ex. does anyone really use ATA over Ethernet?)? Or something related to PCI pass-through that no longer works? If so, again, let me know so I can figure out what hardware support to re-enable. And of course, you can go much further if you're willing to customize your own kernel, either taking out support for hardware you don't have/will never use, or adding in anything that's missing yourself. If you choose to go that route, please share your results. I don't have access to detailed stats or how RAM usage is affected, but anecdotally, a kernel with the stock configuration took up around 200MB of disk space, and my personal slim kernel takes up about 95MB. I assume there's a RAM savings as well, but I've never measured, nor have I measured how performance is impacted (although maybe that's where something like the Phoronix Test Suite could come in once things settle down a bit more). To test, all you need to install is the kernel package that gets generated once you've compiled it and reboot into it. You could also install the kernel-qubes-vm version and use that in a VM; I haven't tested it thoroughly but there may be a RAM savings. I'd recommend using it in a non-networked VM though; it'll still connect to the Internet thanks to TCP/IP support still being included, however, I stripped out stuff like Netfilter/Iptables support, so I don't know how that impacts security. So that's about it. I'm not sure when I'll have more free time again to work on this in depth so there may or may not be more detailed work on this project coming from my end for a few months (limited volunteer hours to spend and all that), but maybe together we can figure out a slimmed-down stock dom0 kernel configuration that would still work for a majority of Qubes OS users out-of-the-box that could be shipped in the future. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/oe5sed%24h8e%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
