linux-kernel - Re: [PATCH v6 0/7] Kernel base address randomization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Oct 2013 07:07:14 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	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>,
	"H. Peter Anvin" <hpa@...or.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


* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/