Messages in this thread | | | Date | Tue, 9 Jan 2018 09:36:18 +0800 | From | Chao Fan <> | Subject | Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory |
| |
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. > >
| |