Messages in this thread | | | Subject | Re: [PATCH v6 0/7] Kernel base address randomization | From | "H. Peter Anvin" <> | Date | Tue, 01 Oct 2013 22:11:37 -0700 |
| |
I think that the randomization offset would be necessary in order to identify pointers.
Ingo Molnar <mingo@kernel.org> wrote: > >* Kees Cook <keescook@chromium.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.
| |