Selfpatch-SLR

Chapters

1. Repository README / getting started guide
2. Overview is where you are at. It specifies the scope and motivation of this project.
3. Architecture explains the full SPSLR pipeline, including terminology, pinpoint, patchcompile, and selfpatch.
4. Bootpatch-SLR describes the Linux-kernel-specific direction.
5. Discussion collects mailing list archive entries and public review material.

Motivation

Structure layout randomization (SLR) is intended to make memory corruption exploitation more difficult by changing the in-memory placement of structure members. Many exploits rely on corrupting a specific member inside a target object, for example function pointers, reference counters, credentials, length fields, or linked-list pointers. Those attacks often depend on the attacker knowing the relative offsets of members within the structure. By randomizing structure layouts, those offsets become less predictable. An overwrite that successfully corrupts a useful target member in one layout may instead corrupt an unrelated field in another layout, potentially causing the exploit to fail or become unreliable.

Doing this at compile-time produces one random but fixed set of layouts per compiled binary. Every deployed instance of that binary shares the same layouts. Thus, an attacker that learns the structure layouts of one deployed instance can produce static exploits based on overwrite primitives that remain valid across all identical instances.

SPSLR investigates a different point in the design space. Instead of treating the randomized layouts as a fixed compile-time property, it moves the final layout decision to runtime. To make that possible, the compiler must expose the places where generated code or static data relies on structure offsets, and the runtime must patch those places after choosing the randomized layout.