On Thu, Dec 01, 2022 at 09:09:04PM +0100, Stefan Bavendiek wrote: > Distributions are commonly shipping the kernel as one large binary > that includes support for nearly every hardware driver and optional > feature, but the end user will normally use very little of this. In > comparison, a custom kernel build for a particular device and use > case, would be significantly smaller. While the reduced complexity > won't be directly linked with reduction in attack surface, from my > understanding the difference would make a relevant impact. I looked into a similar problem back in the day when trying to vet correctness of the Xen hypervisor when you are boooting a Xen guest and not a KVM guest, how do we ensure that code that should not be run should not run? Although it's a separate problem the solution to strive to block / drop code which should not run essentially would accomplish the same goal: prevent dead code to run. It is *one* reason why I ended up implementing linker-tables long ago on Linux, although this didn't get merged. The idea there was that *eventually*, once you have mapped code into a section and you are certain it should not not via ELF sections, you could just drop / NX the code you don't need at runtime. It turns out obviously Linux is not the only place where we could benefit from this sort of work and when I reviewed the prospects on the Qemu with Alexander Graf we instead persued the idea of a GCC compiler multiverse support, and thanks to some researchers that is now real code. All these things are related, and so I started long ago jotting some of the ideas here: https://kernelnewbies.org/KernelProjects/kernel-sandboxing Since linker tables didn't get merged I didn't follow up though but in theory a lot of NX / free'ing dead code shoudl be possible for large parts of text dynamically at runtime. Luis
