linux-kernel - Re: [GIT PULL] x86/kaslr for v3.14

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:	Tue, 21 Jan 2014 15:39:39 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Cong Ding <dinggnu@...il.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>, Kees Cook <keescook@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mathias Krause <minipli@...glemail.com>,
	Michael Davidson <md@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Wei Yongjun <yongjun_wei@...ndmicro.com.cn>
Subject: Re: [GIT PULL] x86/kaslr for v3.14


* H. Peter Anvin <hpa@...or.com> wrote:

> On 01/21/2014 01:00 AM, Peter Zijlstra wrote:
> >>
> >> So this is presumably something that needs to be fixed in perf?
> > 
> > Where do we learn about the offset from userspace?
> > 
> 
> Now this is tricky... if this offset is too easy to get it 
> completely defeats kASLR.  On the other hand, I presume that if we 
> are exporting /proc/kcore we're not secure anyway.  Kees, I assume 
> that in "secure" mode perf annotations simply wouldn't work anyway?

So /proc/kcore is:

  aldebaran:~> ls -l /proc/kcore 
  -r-------- 1 root root 140737486266368 Jan 21 15:35 /proc/kcore

i.e. root only.

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 ...

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/