linux-kernel - Re: [PATCH 3/4] kaslr setup

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: <20140905222741.GB1675@dhcp-17-102.nay.redhat.com>
Date:	Sat, 6 Sep 2014 06:27:41 +0800
From:	Baoquan He <bhe@...hat.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	linux-kernel@...r.kernel.org, ak@...ux.intel.com, mingo@...hat.com,
	whissi@...ssi.de, dyoung@...hat.com, tglx@...utronix.de,
	vgoyal@...hat.com, chaowang@...hat.com
Subject: Re: [PATCH 3/4] kaslr setup_data handling

On 09/05/14 at 10:32am, Kees Cook wrote:
> On Fri, Sep 05, 2014 at 10:08:16PM +0800, Baoquan He wrote:
> > From: Dave Young <dyoung@...hat.com>
> > 
> > X86 will pass setup_data region while necessary, these regions could be
> > overwitten by kernel due to kaslr.
> > 
> > Thus iterate and add setup regions to mem_avoid[] in this patch.
> > Up to now there isn't a official data to state the maximal entries
> > setup data could use. So just set max mem avoid entries 32, hopefully
> > it will be enough. This can be increased later when people report
> > they are using more setup data entries.
> 
> Ew, yes, this is bad. I hadn't seen setup_data while designing the
> mem_avoid stuff. I don't like the fixed 32 entry size here, so let me
> consider some options. I think the mem_avoid logic can just walk the
> setup_data list itself, since that's what it's for. :)

Yes, maybe you are right. But it's hard to say what's the max. I guess
1024 could be enough, after all e820MAX is 128. If people don't think
that eat too much stack.

> 
> Does only kexec use this? I assume other boot loaders must be using this
> too. Is there an easy test case for validating this is fixed?

I don't think only kexec use this. If e820 is not enough, extending the
memory region to setup data is designed for all bootloaders. Kernel will
check memory regions from setup data. 

I can't find a machine with so many memory regions. Dave told me one
person has this kind of machine, will ask him to help test if possible.

About test case, if that machine with many memory regions could put
setup data in 1G, that's very easy to test. Not sure of that.

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