This sounds a bit better than just 'security through obscurity'. Random numbers are used in all public key crypto systems, and we don't describe those systems as STO.
If randomization of the kernel addresses can give 8-12 bits of uncertainty and the kernel will tend to fail in obvious ways if they guess wrong, that's pretty darn good.
By the by, does this 8-12 bits of uncertainty figure hold true for both 32bit and 64bit x86?
Posted May 26, 2011 7:14 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
no, 32 bit has very little flexibility, this is the gains for 64 bit systems
Kernel address randomization
Posted May 27, 2011 22:38 UTC (Fri) by PaXTeam (subscriber, #24616)
[Link]
i386 kernels have 1/2/3GB of kernel space to play with (minus vmalloc/fixmap/gaps/etc), amd64 kernels have 2GB (minus vsyscall/module area/etc). so for practical purposes, you could get the same amount of entropy for both cases.
Kernel address randomization
Posted May 27, 2011 22:49 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
the issue is that that 1/2/3G of kernel space is in a total of 4G of address space, and given the size of the kernel and the alignment requirements, things are a bit limited
on amd64 you have much more address space to work with, so that 2G of kernel space can be moved to far more locations
Kernel address randomization
Posted May 28, 2011 22:13 UTC (Sat) by PaXTeam (subscriber, #24616)
[Link]
> the issue is that that 1/2/3G of kernel space is in a total of 4G of
> address space, and given the size of the kernel and the alignment
> requirements, things are a bit limited
the exact same limits apply to amd64 kernels as well.
> on amd64 you have much more address space to work with, so that 2G of
> kernel space can be moved to far more locations
you're wrong, the kernel image cannot be at arbitrary addresses, it *must* be in the top 2GB of the 64 bit virtual address space. i suggest you study the amd64 ABI and in particular -mcmodel=kernel.