linux-kernel - Re: [PATCH 1/4] kaslr: check user's config too when handle relocations

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: <20140910150432.GA7898@redhat.com>
Date:	Wed, 10 Sep 2014 11:04:32 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Baoquan He <bhe@...hat.com>
Cc:	Kees Cook <keescook@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Deutschmann <whissi@...ssi.de>,
	Dave Young <dyoung@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	WANG Chao <chaowang@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/4] kaslr: check user's config too when handle
 relocations

On Wed, Sep 10, 2014 at 10:53:34PM +0800, Baoquan He wrote:
> On 09/10/14 at 10:30am, Vivek Goyal wrote:
> > On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
>  
>  
> > > In fact, I think below checking will be clearer and works too.
> > > 
> > > 
> > > static void handle_relocations(void *output, unsigned long output_len)
> > > {
> > > 
> > > ...
> > > 
> > > #if CONFIG_X86_64
> > > 
> > > or
> > > 
> > > #if CONFIG_RANDOMIZE_BASE
> > > #ifdef CONFIG_HIBERNATION
> > > 	if (!cmdline_find_option_bool("kaslr")) {
> > >                debug_putstr("No relocation needed... ");
> > >                return;
> > > 	}
> > > #else
> > > 	if (cmdline_find_option_bool("nokaslr")) {
> > >                debug_putstr("No relocation needed... ");
> > >                return;
> > > 	}
> > > #endif
> > 
> > > 
> > > 	if (max_addr > CONFIG_RANDOMIZE_BASE_MAX_OFFSET) {
> > >                 debug_putstr("Random addr is not allowed. No relocation
> > > needed... \n");
> > >                 return;
> > 
> > Hi Bao,
> > 
> > I dont think that this is required or this is correct. kaslr will not
> > choose a physical location which is beyond CONFIG_RANDOMIZE_BASE_MAX_OFFSET,
> > So not sure what will this do.
> > 
> > Just the other check of output_orig == output should fix issue for us.
> > 
> > If one is not passing nokaslr in case of kexec, and kernel is loaded
> > high (say 64G), I think kaslr will automatically move kernel below 1G
> > and handle_relocations() should succeed.
> 
> No, if kernel is loaded high (say 64G), the random kernel location
> choosing won't happen. Since in process_e820_entry() it only accepts the
> memory region which is above output, plus the
> CONFIG_RANDOMIZE_BASE_MAX_OFFSET checking, any kenrel loaded high above
> 1G will not get a new random kernel location. So it's safe in this case.

Ok, if kaslr does not move kernel in this case, that is also fine. Your
other patch will detect this condition and not perform any relocations.
That means kexec should work as it is without passing nokaslr.

> 
> > 
> > In case of kdump we will have to pass nokaslr, as we don't want kernel
> > to move as it could stomp over other things we have loaded.
> 
> For kdump and kexec nokaslr is unnecessary. As you know we always
> call add_buffer with buf_end as 1, this will cause kernel loaded at the
> top of available memory. E.g on my pc with 16G memory, kexec kernel will
> be put nearby 16G, so no random location choosing happen as I said in
> above. For kdump, if reserved memory is at 500M~700M, then kernel will
> be put nearby 700M, the random location choosing also never happen.
> 
> In fact, for some cases I need change kexec-tools user app code, to make
> kernel be put from down to top.

I think we can't rely on where exactly in memory kexec-tools places the
kernel. For kdump case we will have to pass nokaslr to make sure that
kaslr does not move kernel.

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/