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: <20140910145334.GB1887@dhcp-17-102.nay.redhat.com>
Date:	Wed, 10 Sep 2014 22:53:34 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Vivek Goyal <vgoyal@...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 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.

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

> 
> So I would suggest that test and repost the other patch with proper changelog
> and that might be sufficient for now. Only other thing we will need is
> Kees's patch for avoiding setup data regions in kaslr.

Anyway, it's great people think the "output_orig=output" is good and can
solve our problems, and it does change less code. I can repost that one
with your suggestion that put some comments above that.

Thanks for your comments and suggstion.

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