KASLD: Derandomizing the Linux Kernel Memory Layout From a Local Process

What KASLD Recovers, and What It Refuses to Claim

KASLR randomizes where the kernel sits in memory so that an attacker cannot hardcode addresses. KASLD attacks that randomization from the inside of a running system rather than from a remote vantage. The README states its purpose plainly: it recovers the kernel's virtual and physical memory layout, primarily the kernel text base, from a local process, using as much as the process's vantage allows.

The design choice worth noticing is what happens when recovery fails. The inference engine fuses evidence from dozens of independent techniques with the architecture's known invariants and reports a residual window as a surviving slot count and bits of entropy. The README calls this "an upper bound on the protection KASLR retains from this vantage, not a guarantee the base is beyond an attacker's reach", and points at docs/limitations.md for the reasoning. That is an unusually honest framing. A tool that returns a narrowed window rather than a single address is telling you something about the strength of the mitigation, not just about the target.

The intended audience follows from that. This is a research and exploitation tool, not a hardening scanner. If you want to know how much entropy your kernel configuration actually leaves to an attacker with a given set of capabilities, KASLD is built to answer that question.

How the Vantage Model Shapes Every Result

KASLD does not treat privilege as a single ladder. The README defines vantage as the combination of three independent axes: privileges, groups and capabilities; system configuration; and confinement such as namespaces or seccomp sandboxes.

The independence is the point. A container granted CAP_SYS_RAWIO is init-namespace root for the /proc/kcore check and can read a file an ordinary user cannot reach, while distributions differ over whether /boot/System.map is world-readable at all. Configuration cuts the other way: root cannot read /proc/kallsyms under kptr_restrict=2, yet a relaxed sysctl or unprivileged BPF can hand a plain user a leak that a hardened system would deny. Side channels bypass the sysctls entirely.

The README makes a claim here that is easy to misread: the reported guaranteed window never depends on privilege. Elevated access or a weak configuration can widen what is attempted, never the sound layout the evidence proves. So the tool separates what it tried from what it can defend, and the -v, -j and -m outputs report the detected vantage, including container status, confinement and the capability-gated leaks reachable from the current process. If you are comparing two hosts, compare the vantage blocks before comparing the answers.

Installing KASLD and Reading a First Run

The README gives a four-command quick start on Debian-style systems. It installs the build dependencies, clones the repository, builds, and runs the binary for the host architecture.

sudo apt install libc-dev make gcc binutils git
git clone https://github.com/bcoles/kasld
cd kasld
make
./build/<arch>/kasld

Replace <arch> with the architecture directory produced by make. The README describes build/<arch>/ as self-contained and deployable to a target system, containing the kasld binary and a components/ directory of leak components. That matters for the workflow this tool assumes: you build on a machine with a toolchain and copy the directory to the machine you are actually studying.

Run with no flags and you get the answer-first text mode. The README's example output shows a progress line reporting how many of the available components ran, then a table with columns for Quantity, Certainty, Window, Candidates and Grain. In that example the Virtual Image Base row reads "guaranteed" with a slide and "1 of 505" candidates at 2 MiB grain, and the Physical Image Base row is guaranteed at 0x20000. Other output modes exist: -v for the full verbose readout with per-component logs and memory-layout maps, -j for machine-readable JSON that always includes per-component records and the hardening assessment, -1 for a single shell-pipeable line, -m formatted for issue trackers, and -H to append the hardening assessment to the text or Markdown report.

The Build Is Not a Plain CFLAGS Compile

The Makefile carries a constraint that is easy to miss if you only skim the README. Most components are compiled at -O2, but side-channel components that rely on precise timing or speculative execution are compiled with -O0. The comment in the Makefile explains why: the compiler may reorder memory operations around rdtsc and rdtscp timing, eliminate volatile accesses used for Flush+Reload cache probing, or reschedule instructions across mfence and lfence serialization barriers, destroying the timing signal.

If you fork KASLD and add a component, this is the first thing to check. A new timing-based leak compiled at the default optimization level may appear to work while measuring nothing. The diagnostics flags are also probed at make time with cc-option, so flags the compiler does not recognize drop out rather than generating noise. The Makefile comment says this keeps the build portable across older gcc, clang and musl, and enumerates which diagnostics are gcc-only. The practical consequence is that a warning you see locally may not appear on another toolchain, and vice versa.

Where KASLD Fails, and Why That Is Not a Clean Bill of Health

The README is direct about the hard case. On a fully-patched modern kernel, where x86-64 side channels are mitigated and no direct kernel-text leak survives, full recovery is often impossible. The constraint set is rarely empty, but rarely empty is not the same as useful.

That distinction is the failure mode worth internalizing. A negative or partial result does not prove the kernel base is safe from an attacker with a different vantage. docs/limitations.md is listed in the documentation index under "Interpreting results" with the description "sound-but-not-complete, and why a failure is not a security guarantee". Anyone citing a KASLD run as evidence that a system is protected is reading the output backwards.

There is a second cost that the documentation names rather than hides. docs/footprint.md covers what a run looks like on a monitored host: the behavioural signature to detect it, and the operator's OPSEC cost. The README's summary of that page is two words, "loud by design". A tool that runs 106 of 109 components and takes tens of seconds is not quiet, and the documentation says so. If your scenario requires not being noticed, KASLD is the wrong instrument.

KASLD Versus Reading the Leak Sources Yourself

The obvious alternative is not another derandomization tool but the manual approach: read /proc/kallsyms, /proc/kcore, /boot/System.map or the kernel logs yourself and parse what you find. For a single known leak on a permissive system, that is faster than building anything.

The difference in approach is that KASLD treats each source as one piece of evidence rather than an answer. The inference engine fuses evidence from dozens of techniques with the architecture's known invariants, and the README's example run reports 106 of 109 components executed, with 3 experimental ones skipped unless -x is passed. A manual read of /proc/kallsyms gives you one address or one denial. KASLD gives you a window with a candidate count and a grain, plus a per-component record in JSON explaining which sources contributed.

That structure is also what makes the tool portable across the supported architectures: x86 from i386 upward, ARM from armv6 through aarch64, MIPS, PowerPC, RISC-V, LoongArch and s390. On architectures without KASLR, the README states the engine locates the bootloader-chosen load address. A hand-rolled parser for one arch does not survive that range. The trade-off is weight: 109 components, a build step, and a self-contained directory to deploy, against a few lines of shell for the narrow case.

Licence, Maintenance and the Cost of Keeping Up

KASLD is MIT licensed, with a THIRD-PARTY-NOTICES.md at the repository root for bundled code. MIT is permissive, so embedding the tool or its components in another project carries few obligations beyond preserving the notice. The repository also ships a CITATION.cff, which suggests the authors expect academic use. None of this is legal advice; check the notices file against your own distribution plans.

The last push to master was on 2026-06-18, the same date as the v0.3.0 release, following v0.2.0 on 2026-06-02 and v0.1.1 on 2026-04-27. The repository is not archived. The upgrade cost is not the code, which builds with make and a C compiler, but the component surface. Components target specific kernel versions, configurations and CVEs, and docs/bypass-techniques.md is organized around patched CVEs and syscall or ioctl leaks. A kernel upgrade can retire components without any change to KASLD itself. Budget for re-running the tool against each new kernel you care about rather than assuming a pinned build stays accurate.

Editorial conclusion

KASLD suits security researchers and exploit developers who need to reason about the kernel text base from a local process, and who will read docs/limitations.md before trusting a result. It is the wrong tool for anyone expecting a guaranteed bypass on a fully-patched modern kernel, where the README itself says full recovery is often impossible. Before adopting it, run `./build/<arch>/kasld` on a representative target and check the hardening assessment in the `-v` or `-j` output against the sysctls actually set there.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes