lkml.org 
[lkml]   [2018]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@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.

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

    \
     
     \ /
      Last update: 2018-01-14 23:17    [W:4.063 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site