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

[Ard Biesheuvel]

Hello Jasper,

This work looks very interesting, thanks for sticking with it.
That said, I think the path to possible upstream inclusion is
rather uncertain, given the intrusive nature of this work.


On Mon, 20 Jul 2026, at 21:11, York Jasper Niebuhr wrote:
> Hello,
> this is the third RFC version of Bootpatch-SLR. The previous RFCs were
> sent to linux-hardening; this version is also sent to LKML for broader
> review. Compared to RFC v2, it uses a new GAS feature instead of a
> dedicated assembler inside the compiler plugin. Additionally, it
> introduces the Sanemaker validation framework. This version rebases
> BPSLR onto Linux 7.2-rc3 and resolves the boot failures that prevented
> earlier rebases.
>
> RFC v2:
>     https://lists.openwall.net/linux-hardening/2026/06/20/5
>
> Changes since RFC v2:
>   - Implemented GAS fieldlabel feature to label immediate instruction
>     operand bytes.
>   - Removed pinpoint instruction pin assembler. Metadata now links
>     directly against fieldlabels emitted by GAS.
>   - Implemented Sanemaker validation tool and integrated it into the
>     kernel.
>   - Rebased Bootpatch-SLR onto Linux 7.2-rc3.
>   - Excluded some RCU fields of task_struct from randomization to
>     prevent boot crashes on new version.
>
> Bootpatch-SLR enables per-instance structure layout randomization for
> distribution kernels. While GCC's RandStruct pass randomizes layouts at
> compile-time, every machine running the same kernel image receives the
> same layout. Bootpatch-SLR applies comparable randomization during boot.
>

I take it this means that DWARF debug data and BTF typeinfo are no longer
usable on such kernels? If so, how does that impact BPF?


> A full architectural overview and additional resources are available at:
>
>     https://spslr.yjn-systems.com
>
> At this stage, tooling is only available for x86_64. It is based on
> Linux 7.2-rc3. Bootpatch-SLR currently randomizes most of the
> task_struct. A few fields are exempt from randomization because of
> current implementation details (see v2 cover letter).
>
> Bootpatch-SLR requires a custom toolchain based on GCC 16.1.0 and GAS
> 2.46.1. GCC is extended to provide access to COMPONENT_REFs that are
> usually folded inside the parser.

How does this impact codegen and optimizations in particular? I suppose
keeping individual field offsets patchable results in missed optimization
opportunities? E.g., GCC may combine adjacent struct member accesses.

It would be good to get some numbers in terms of code size increase in
general, as well as I-cache efficiency on some representative benchmarks.

> The custom GAS provides the new
> fieldlabel feature used to annotate encoded instruction patch sites.
>
> An example for the fieldlabel feature is:
>
>     movq $fieldlabel(8, .Lspslr_ipin_42, .Lspslr_ipin_width_42), %0
>
> This causes the custom GAS to put the .Lspslr_ipin_42 label directly
> onto the bytes encoding the immediate value 8. It additionally defines
> the .Lspslr_ipin_width_42 label to be the size of the immediate field.
> The metadata emitted by the Pinpoint plugin directly references these
> symbols to specify exact patch-site locations.
>

Does the fieldlabel feature have any other uses? Or is this only for
SPSLR. Could these changes be extended to DWARF metadata generation too?

For example, it might be useful to be able to capture the SPSLR seed
(assuming there is one), and feed it into a host tool that can generate
a matching vmlinux.elf that you can load into the debugger.