Couldn't they do something that's "repeatably random"? So that in case of a bug, you can extract some information from your kernel on its current randomisation, and then another kernel can use this information to repeat your random layout.

E.g. use pseudorandom numbers, store the seed somewhere. In case of a bug, extract that seed, pass it on to the dev, and he'll run his kernel with that seed to reproduce.

How do you prevent an attacker from getting the seed? This would just create a possible attack vector that could be used to effectively disable address space randomization.

e.g. only root can get access to the seed. Then the attacker would already need to have root, so then you're in huge trouble anyways. And yes, it may be weaker than a full-random solution. But a pseudorandom system that gets accepted is more secure than a full-random system that doesn't get accepted.

This would sort of negate the purpose of ASLR, as afaik the whole point is an attacker would not know the mem layout. The very fact its not reproducible is the solution and the problem!

No. If the seed would be made available only in a kernel bug report.

Yes, that is what frederikvs probably means but access to the seed could become a new weakest link of ASLR. Presumably only available to CAP_SYS_ADMIN/uid 0, but it's worth a great deal of caution in designing the feature that allows determining what the seed was.

Further adding to that, the seed could be changed before that bug report was submitted. A dedicated tool with a FSM and minimal privileges does it. That lets us verify it strongly.

I know of a few "one time in a billion" bugs that became "one time in a hundred" bugs after randomization. Then they were fixed, instead of continuing to linger.

That's a form of fuzzing. With fuzzing, when you find something unexpected, you replicate the situation and explore that neighborhood. You don't immediately go on to the next random try.

Yes. And fuzzing works better by conscripting more users. :)

I didn't get that argument really. Or specifically, do we know the number of bugs which are harder to debug because now they disappear -vs- the number of bugs which were detected because kaslr breaks invalid assumptions? Maybe kaslr just exposed some ticking bombs in the code.

I've certainly seen this for user ASLR. However it's easy to work around, you just turn off ASLR while reproducing your bug. There's a knob to tweak in /proc/sys/kernel.

Doesn't help much. Turning ASLR off for a memory-clobbering bug adds repeatability, but it may be repeatable as in "never fails" if the memory clobbered isn't important. Memory is big today; most random stores won't crash the system. Now it's a "cannot reproduce" bug.

Crash reports from production systems come in, and you try to classify them. If the crashes look similar, you have something to look for. (Microsoft has a classifier to do this for Windows crashes, and that's one reason the Windows Blue Screen of Death is rare today.) Then you try to reproduce the crash situation. ASLR adds noise to that data. It's harder to match up similar bug reports.

It'll take at least a decade until kernel developers are convinced that KASLR is not helping anyone, and infoleaks are defeating it on a daily basis.

Here, have 3: https://twitter.com/R00tkitSMM/status/796617449823236096

(no, I didn't get confused, KASLR is not helping regardless of the OS)