linux-kernel - Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

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]

Date:   Mon, 8 Jan 2018 09:39:54 -0500
From:   Luiz Capitulino <lcapitulino@...hat.com>
To:     Chao Fan <fanc.fnst@...fujitsu.com>
Cc:     Baoquan He <bhe@...hat.com>, <linux-kernel@...r.kernel.org>,
        <x86@...nel.org>, <hpa@...or.com>, <tglx@...utronix.de>,
        <mingo@...hat.com>, <keescook@...omium.org>,
        <yasu.isimatu@...il.com>, <indou.takao@...fujitsu.com>,
        <caoj.fnst@...fujitsu.com>, <douly.fnst@...fujitsu.com>
Subject: Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to
 specify extracting memory

On Fri, 5 Jan 2018 10:58:11 +0800
Chao Fan <fanc.fnst@...fujitsu.com> wrote:

> On Thu, Jan 04, 2018 at 06:30:57PM +0800, Baoquan He wrote:
> >On 01/04/18 at 04:02pm, Chao Fan wrote:  
> >> In current code, kaslr may choose the memory region in movable
> >> nodes to extract kernel, which will make the nodes can't be hot-removed.
> >> To solve it, we can specify the memory region in immovable node.
> >> Create immovable_mem to store the regions in immovable_mem, where should
> >> be chosen by kaslr.
> >> 
> >> Also change the "handle_mem_memmap" to "handle_mem_filter", since
> >> it will not only handle memmap parameter now.
> >> Since "immovable_mem=" only works with "movable_node", so "immovable_mem="
> >> doesn't work alone. If specify "movable_node" without "immovable_mem=",
> >> disable KASLR.
> >> 
> >> Multiple regions can be specified, comma delimited.
> >> Considering the usage of memory, only support for 4 regions.
> >> 4 regions contains 2 nodes at least, enough for kernel to extract.
> >> 
> >> Signed-off-by: Chao Fan <fanc.fnst@...fujitsu.com>  
> >
> >Hi Chao,
> >
> >Thanks for your effort on this issue.
> >
> >Luiz told me they met a hugetlb issue when kaslr enabled on kvm guest.
> >Please check the below bug information. There's only one available
> >position which hugepage can use to allocate. In this case, if we have a
> >generic parameter to tell kernel where we can randomize into, this
> >hugepage issue can be solved. We can restrict kernel to randomize beyond
> >[0x40000000, 0x7fffffff]. Not sure if your immovable_mem=nn[KMG]@ss[KMG]
> >can be adjusted to do this. I am hesitating on whether we should change
> >this or not.
> >  
> 
> Hi Baoquan, Luiz,
> 
> In my personal understanding, there is only one region,
> [0x40000000, 0x7fffffff] suitable for the 1G page, so we should avoid
> kaslr to choose this region, right?

For a guest configured with 4GB of memory with the device configuration
we're using yes.

> If my understanding is right, I think it's more similar with mem_avoid.
> Because we specify where KASLR *choose* in "immovable_mem=", we specify
> where KASLR *avoid* in "mem_avoid".
> So I wonder if it's OK to expand mem_avoid, and add a member like
> MEM_AVOID_HUGEPAGE in "enum mem_avoid_index".
> But there is a disadvantage, we can only specify the limited regions.

Not requiring new command-line options would be great for users,
but I'm not sure it's possible to use mem_avoid because I guess the
free area may vary depending on amount of memory, devices, etc.

> Luiz, I am not familiar with HUGE PAGE, I wonder how many 1G HUGE pages
> does system need in general? We may need to limit it in 2, or 4.

I don't think it's possible to impose a limit. But the case we've
been discussing in this thread it the case that has the greater
impact: a guest with 4GB of memory which always has 1GB page with nokaslr,
but may not have any 1GB page without nokaslr.