| |||||||||||||
Kernel address randomizationKernel address randomizationPosted May 27, 2011 12:50 UTC (Fri) by deater (subscriber, #11746)Parent article: Kernel address randomization
This should make bisecting a kernel problem fun, especially if the address layout only makes the problem appear on average half the time.
Same with trying to reproduce a hang that locks your system only some of the time. Did you remember to write down the random offset at boot-time just in case?
There can also be interesting performance analysis implications. Randomized userspace processes can vary a few percent in performance when randomized if poorly written (SPEC 2000 perlbench (*cough*)). Things like taking addresses of variables and using them as keys in hash tables, etc.
(Log in to post comments)
Kernel address randomization Posted May 27, 2011 22:10 UTC (Fri) by oak (subscriber, #2786) [Link]
>This should make bisecting a kernel problem fun, especially if the address
>layout only makes the problem appear on average half the time.
>Same with trying to reproduce a hang that locks your system only some of
If the crash happens always "at the same place", and the kernel address is e.g. 4kB aligned, the lower bits would still be the same and could work as identification.
Kernel address randomization Posted May 28, 2011 20:42 UTC (Sat) by viro (subscriber, #7872) [Link]
... and if the crash depends on the location of kernel and simply doesn't happen on half of the boot attempts due to differences in that? Good luck narrowing things down to commit that has caused it...
Kernel address randomization Posted Jul 11, 2011 4:40 UTC (Mon) by kevinm (guest, #69913) [Link]
So long as the Oops includes the blinding value that was in use, and you can force it for subsequent testing via kernel command-line, that should be enough.
|
|||||||||||||