Build a monolithic kernel

[legoktm]

At #45 (comment) @thedeadliestcatch wrote:

I would strongly suggest considering building monolithic kernels with a minimal config. If you transition away from HVM to pvgrub, and even if you don't, it will be a good idea. Removing LKM support has several benefits in terms of reducing attack surface in the kernel for ROP and code injection scenarios (after all, LKM support comes with the implicit need for a dynamic linker in kernel space).

I replied:

This is a good point and something I started wondering about mid-last week, whether there was any benefit to building individual modules. I'll look into doing a monolithic build.

From what I can tell we just need to change all the m settings to y and then turn off CONFIG_MODULES. We should make sure that the blacklisted modules (see freedomofpress/securedrop#1886) are disabled at build-time as well.

[thedeadliestcatch]

Remember to verify against issues with <1G initial memory Qubes. Because of KERNEXEC/UDEREF and other modifications, it's highly unlikely that the guests will boot gracefully if they are left with the initial memory set to anything less than 1024MB.

Other than that, there should be no issues.

PS: This caveat emptor is most relevant when problems happen in any of the more critical Qubes, ex. sys-net and sys-usb and equivalent ones. Generally speaking, anything that will result in a dom0 PCI handoff to a subdomain/Qube, will break the user experience once that Qube starts. ex. a broken sys-usb will result in non-functional input devices if using USB keyboards/mice.

So, whenever a template is used for qubes with one of these kernels, you might need to adjust initial memory so that it is at least 1G.

[legoktm]

Oh heh, we already have an open issue about needing at least 1G memory: freedomofpress/securedrop-workstation#838. I never got around to digging into it further, are you saying it's just a requirement of the grsec patches?

[zenmonkeykstop]

That shouldn't be a problem to set up, we can set the initial memory when we clone the templates used for sd-* app/dispvms.

[thedeadliestcatch]

Oh heh, we already have an open issue about needing at least 1G memory: freedomofpress/securedrop-workstation#838. I never got around to digging into it further, are you saying it's just a requirement of the grsec patches?

Yes, they do require 1024M AFAIK.

The issue you referenced is true. Do note that you can set a reasonably low maximum as well.

The low initial memory setting does not correlate with real/actual use. I would be very surprised if Qubes' sys-usb and sys-net occupy less than 1G, and in fact, in the default settings, they are quickly ballooned up to the maximum or near.