Date: Tue, 9 Jan 2018 09:36:18 +0800
From: Chao Fan <fanc.fnst@cn.fujitsu.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
CC: Baoquan He <bhe@redhat.com>, <linux-kernel@vger.kernel.org>,
        <x86@kernel.org>, <hpa@zytor.com>, <tglx@linutronix.de>,
        <mingo@redhat.com>, <keescook@chromium.org>,
        <yasu.isimatu@gmail.com>, <indou.takao@jp.fujitsu.com>,
        <caoj.fnst@cn.fujitsu.com>, <douly.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to
 specify extracting memory
Message-ID: <20180109013614.GA13719@localhost.localdomain>
References: <20180104080219.23893-1-fanc.fnst@cn.fujitsu.com>
 <20180104080219.23893-2-fanc.fnst@cn.fujitsu.com>
 <20180104103057.GC7235@x1>
 <20180105025810.GA7714@localhost.localdomain>
 <20180108093954.51dccabf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20180108093954.51dccabf@redhat.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org

On Mon, Jan 08, 2018 at 09:39:54AM -0500, Luiz Capitulino wrote:
>On Fri, 5 Jan 2018 10:58:11 +0800
>Chao Fan <fanc.fnst@cn.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@cn.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.
>

OK, I got it. So the old command-line iptions may not suit this issue.
I will try to think about it.
I don't know if other people have a good idea.

Thanks,
Chao Fan

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