Date: Tue, 01 Oct 2013 22:11:37 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Ingo Molnar <mingo@...nel.org>, Kees Cook <keescook@...omium.org> CC: linux-kernel@...r.kernel.org, x86@...nel.org, kernel-hardening@...ts.openwall.com, adurbin@...gle.com, Eric Northup <digitaleric@...gle.com>, jln@...gle.com, wad@...gle.com, Mathias Krause <minipli@...glemail.com>, Zhang Yanfei <zhangyanfei@...fujitsu.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Arnaldo Carvalho de Melo <acme@...radead.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [PATCH v6 0/7] Kernel base address randomization I think that the randomization offset would be necessary in order to identify pointers. Ingo Molnar <mingo@...nel.org> wrote: > >* Kees Cook <keescook@...omium.org> wrote: > >> Here is the latest version of the kASLR series. It has much improved >> e820 walking code, and expands the window available on 64-bit. >> >> This is rolled out on Chrome OS devices, and working well. > >There's one kernel debuggability detail that should be discussed I >think: >should symbolic printouts (in oops messages but also in /proc/kallsyms) > >and instrumentation interfaces that expose kernel addresses attempt to >de-randomize the addresses, stack contents and register values that lie > >within the random range? > >- it would be easier to use those addresses and look them up in a >vmlinux > or in a System.map as well. > > - it would be somewhat safer to post an oops publicly if it did not > contain the random offset in an easily identifiable way. > >- oops patterns from distribution kernels that enable randomization >would > match up better. > > - this would make it safer to expose /proc/kallsyms to user-space > profiling, while keeping the random offset a kernel-internal secret. > > - RIP information in profiling streams would thus not contain the > kernel random offset either. > >The other approach would be what your series does, to keep all the raw, > >randomized output and to assume that users who are allowed to access to > >logs or profiling can learn the random offset. > >I tend to lean towards the 'raw' approach that you picked, but an >argument >can be made for both approaches - and in any case I haven't seen this >discussed to conclusion with cons/pros listed and a consensus/decision >reached. > >Thanks, > > Ingo -- Sent from my mobile phone. Please pardon brevity and lack of formatting.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.