linux-hardening - Re: Reducing runtime complexity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y46m+rhDe7otOFpp@bombadil.infradead.org>
Date:   Mon, 5 Dec 2022 18:20:42 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Stefan Bavendiek <stefan.bavendiek@...lbox.org>,
        "H. Peter Anvin" <hpa@...or.com>
Cc:     kernel-hardening@...ts.openwall.com,
        linux-hardening@...r.kernel.org
Subject: Re: Reducing runtime complexity

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