lkml.org 
[lkml]   [2014]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2014-01-21 16:42    [W:0.082 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site