Messages in this thread | | | Date | Tue, 21 Jan 2014 15:56:15 +0100 | From | Ingo Molnar <> | Subject | Re: [GIT PULL] x86/kaslr for v3.14 |
| |
* H. Peter Anvin <hpa@zytor.com> wrote:
> > The thing is, one of my first remarks on this whole KASLR series > > was that tooling needs to work. I suggested that the kernel should > > only expose non-randomized addresses and that all facilities need > > to continue to 'just work' with those. That argument was ignored > > AFAICS and the problem still isn't solved. > > > > I'd argue that solving it in the kernel instead of making all > > tooling variants aware of KASLR one by one is a far more > > intelligent and efficient solution ... > > Not ignored, but found not to really work all that well (we had that > discussion in the context of relocated kernels, too.) The problem > you end up with is that as soon as you run into situations where you > have to deal with pointers during debugging, be it using kgdb, stack > dumps or whatever, all the work that you have done in the kernel to > try to hide relocation from the debug infrastructure all of a sudden > becomes a huge liability, and ends up backfiring in a horrific way.
The thing is, that 'huge liability' is now pushed into tooling, which isn't in any better position to judge a piece of data in a backtrace than the kernel - in fact it's in an arguably worse position, as it does not generate that data.
kgdb is an entirely different animal, I'm talking about the 99% usecase: code profiling and tooling interpreting code addresses that come from the kernel.
Thanks,
Ingo
| |