Re: [RFC 0/7] Bootpatch-SLR: Randomizing Linux Kernel Structure Layouts at Boot

[Kees Cook <kees@kernel.org>]

On Fri, Jun 05, 2026 at 10:25:04PM +0200, York Jasper Niebuhr wrote:
> my name is York Jasper Niebuhr. I am a Master's student in Informatics
> at the Technical University of Munich.
> 
> For a while now, I have been developing Selfpatch-SLR (SPSLR), a system
> to apply Structure Layout Randomization at runtime, and its Linux kernel
> implementation, Bootpatch-SLR (BPSLR), as an independent research
> project in my spare time. I am now beginning my Master's thesis, which
> will build upon and further evaluate this work. This patch series
> contains the current state of Bootpatch-SLR.

Thanks for working on this! I asked the Sashiko folks to give this
series a review, just so you have some more immediate feedback:
https://sashiko.dev/#/patchset/20260605202511.79272-1-yjn%40yjn-systems.com

I'd love to get Ard's feedback on this series too; he's done a lot of
poking around at layouts, annotation sections, etc.

As was mentioned at the KSPP meeting (thank you for attending!) one
aspect for further down the road will be getting this implemented
directly in GCC and Clang (since no new GCC plugins will be accepted in
Linux). But in the meantime, I think it would be best to move the plugin
into the existing GCC plugin infrastructure in the kernel (see
scripts/gcc-plugins/), as that should better control when it gets built,
make dependencies, and when it gets enabled for various build stages.

> The design goal of SPSLR is to eliminate the need for runtime lookup
> tables or similar indirection mechanisms. Structure access instructions
> are patched directly to reflect the randomized field offsets before
> normal kernel execution begins.

The implementation looks very similar to relocation fixups; is it
possible to create a new relocation type for this so it more naturally
fits into the ELF image? The .data/.rodata annotations likely need to
remain a separate section, similar to how existing things like fault
instrumentation works (i.e. from the sanitizers for things like KCFI,
UBSAN, etc).

>  * Patch 7 ignores BPSLR-generated files.

You can just fold this into the patches that add the build outputs.

> I have also attempted to port BPSLR to v6.18 and later releases. While I
> got the system to build, occasional runtime failures currently prevent
> successful operation.

I do wonder if getting the plugin merged into Linux's gcc plugin
infrastructure would solve this (i.e. it would get run/not run at the
right times, etc). I suppose it's possible it won't help, of course.

> In particular, I would be interested in pointers to areas that are
> likely to require special handling, as well as assumptions made by the
> kernel that may not be obvious to someone approaching the problem from
> outside the subsystem in question.

Targeting task_struct is quite a challenge! I wonder if you might want
to start with a different subset of the __randomize_layout-marked
structs? I know there are a bunch of filesystem and network structs that
maybe aren't quite as sensitive to early boot like I imagine task_struct
is.

What did you need to make exceptions for in the task_struct? I suspect
that may also be a hint as to why getting this ported to the latest
kernel isn't easy?

-Kees

-- 
Kees Cook