On Sun, Jan 26, 2014 at 10:49 PM, Richard Weinberger <richard.weinber...@gmail.com> wrote: > On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin <h...@linux.intel.com> wrote: >> On 01/26/2014 02:16 AM, Richard Weinberger wrote: >>> >>> Currently we print the kernel offset only upon a panic() using the >>> panic notifier list. >>> This way it does not show up if the kernel hits a BUG() in process >>> context or something less critical. >>> Wouldn't make more sense to report the offset in every dump_stack() or >>> show_regs() call? >> >> No, because that information is available to user space unless we panic. > > Didn't you mean non-root? > I thought one has to set dmesg_restrict anyways if kASLR is used. > > And isn't the offset available to perf too? > Of course only for root, but still user space.
Setting dmesg_restrict is done mostly in an effort to try to lock down access to dmesg since it'll likely contain enough clues to help an attacker. System owners need to avoid dmesg getting sprayed into /var/log world-readable, or available via privileged debugging daemons, etc. Since keeping dmesg secret from non-root users is going to be error-prone, I had a goal of keeping the offset out of dmesg while the system is still running -- hence doing it only at panic time. Finding the offset as the (unconfined) root user is extremely easy, so I personally see no reason to hide it from root (and it would be very irritating for things like perf, too). I view kASLR as a tool for statistical defense against confined processes or remote attacks. I would argue that decoding a non-panic oops on a running system is entirely possible as-is, since the offset can be found from /proc/kallsyms as root. It was the dead system that needed the offset exported: via text in the panic, or via an ELF note in a core. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/