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]

Message-ID: <20140130220708.GP9951@redhat.com>
Date:	Thu, 30 Jan 2014 17:07:08 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Richard Weinberger <richard.weinberger@...il.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Cong Ding <dinggnu@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Ingo Molnar <mingo@...nel.org>,
	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

On Sun, Jan 26, 2014 at 10:51:06PM -0800, H. Peter Anvin wrote:
> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> >>
> >> 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.
> > 
> 
> For certain system security levels one want to protect even from a rogue
> root.  In those cases, leaking that information via dmesg and perf isn't
> going to work, either.
> 
> With lower security settings, by all means...

I am wondering if kdump functionality is impacted with this change.

Kexec tools prepares ELF headers for kernel memory ranges and for the
range where kernel text is mapped. So it needs to know virtual address
of the region where kernel is mapped (obtained by /proc/kcore) and
it gets the physical address where kernel is loaded from /proc/iomem.

So with this change are we planning to hide kernel text virtual address and
physical address information information from root in /proc/kcore and
/proc/iomem in anyway?

Thanks
Vivek
--
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/