linux-kernel - Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed

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: <20141013151955.GA9777@redhat.com>
Date:	Mon, 13 Oct 2014 11:19:55 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Baoquan He <bhe@...hat.com>, Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, ak@...ux.intel.com, ebiederm@...ssion.com,
	kexec@...ts.infradead.org, whissi@...ssi.de,
	kumagai-atsushi@....nes.nec.co.jp, stable@...r.kernel.org
Subject: Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed

On Mon, Oct 13, 2014 at 08:52:57AM -0400, Vivek Goyal wrote:
> On Sat, Oct 11, 2014 at 03:34:29AM -0700, H. Peter Anvin wrote:
> > On 10/10/2014 08:14 PM, Baoquan He wrote:
> > >On 10/08/14 at 03:27pm, Vivek Goyal wrote:
> > >>On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
> > >
> > >>>Sorry... this makes no sense.
> > >>>
> > >>>For x86-64, there is no direct connection between the physical and
> > >>>virtual address spaces that the kernel runs in...
> > >>
> > >>I am sorry I did not understand this one. I thought that initial
> > >>relocatable kernel implementaion did not have any direct connection
> > >>between virtual and physical address. One could load kernel anywhere
> > >>and kernel virtual address will not change and we will just adjust
> > >>page tables to map virtual address to right physical address.
> > >>
> > >>Now handle_relocation() stuff seems to introduce a close coupling
> > >>between physical and virtual address. So if kernel shifts by 16MB
> > >>in physical address space, then it will shift by equal amount
> > >>in virtual address space. So there seems to be a direct connection
> > >>between virtual and physical address space in this case.
> > >
> > >Yeah, it's exactly as Vivek said.
> > >
> > >Before kaslr was introduced, x86_64 kernel can be put anywhere, and
> > >always _text is 0xffffffff81000000. Meanwhile phys_base contains the
> > >offset between the compiled addr (namely 0x1000000) and kernel loaded
> > >addr. After kaslr implementation was added, as long as kernel loaded
> > >addr is different 0x1000000, it will call handle_relocations(). The
> > >offset now is added onto each symbols including _text and phys_base
> > >becomes 0.
> > >
> > >It's clearly showing that by checking /proc/kallsyms and value of
> > >phys_base.
> > >
> > 
> > This really shouldn't have happened this way on x86-64.  It has to happen
> > this way on i386, but I worry that this may be a serious misdesign in kaslr
> > on x86-64.  I'm also wondering if there is any other fallout of this?
> 
> I agree. On x86_64, we should stick to previous design and this new
> logic of performing relocations does not sound very clean and makes
> things very confusing.
> 
> I am wondering that why couldn't we simply adjust page tables in case of
> kaslr on x86_64, instead of performing relocations.

Well, IIUC, if virtual addresses are shifted w.r.t what virtual address
kernel was compiled for, then relocation will have to be done.

So question will be if physical address shift is enough for kaslr or
virtual address shift is necessary.

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/