Re: Reducing runtime complexity

[Luis Chamberlain <mcgrof@kernel.org>]

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