Received: by 10.223.148.5 with SMTP id 5csp7445252wrq; Thu, 18 Jan 2018 05:40:26 -0800 (PST) X-Google-Smtp-Source: ACJfBosPXpuw+DBDbEK06U/5jxd/wg2h7Jw12EptE1j+xjGWkfXTeLUn1Bu7TGWakGHsxfJux2PC X-Received: by 10.99.107.73 with SMTP id g70mr19221684pgc.281.1516282826816; Thu, 18 Jan 2018 05:40:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516282826; cv=none; d=google.com; s=arc-20160816; b=RbSAvfBXk2PX6NRSqqH4lFCJoqNh3RE2mq7pkBepUdaNMA48Sp9qTG+k3V7G/YGXW/ xzXmIKb3VEDVMFFm3NQpoaYvUG3akcIdD0zRM+izdIEduiULRZ956VhRathYz34ww9os kUvKwKUiK+l7ORhfVcSz5Rqj7OyQAyEuZhWEU0sbHVW75+pXiaY79AXqGVHpnGZWN8sS /E+tb29W/nM3AxInn+9v3wjPZsC3kVQWhwJ6nM6IypJrV/AA97pgo+9DMNj0ZYyjD7k0 qmLqUELP6Fdwtag7tNI4DSWoUka87chMB/nbiDL5DugIK8YJrW4SzK1c9TYqKU6ZIzM5 IUQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=ZGz3V1dVjM8mKuU/N9lpUjW4bvv6db4Qpg6lHrC5Uzg=; b=DhJd5BPbYNCEKbc9CUpDq8It9+ADBT/ivVLosPDMOwVjEiDEiCqhOnQcZXGYh/AWfj qbilCpFvq2p5JC7AHrm8w9kexjF17SqQUocJBZEhI4kFbl3lE3gzJMtt9m436h0WYSIL laxstaNPyfsV9nV1ESFPb0dI+IcufuJG1h7hl55f8Du34grpxkTibtbR9ToQXjMTSaDN 89bXp3qhFt7F4sLeCJnzHhxIPgOE0j/gAxC4KRbvd8h5qpnbLQx6ZKu6vPni1RZPdCb9 JsOS5lQocPpjKQztv+Z9dL5Rm65Dyw4xkq4RZeY0BxKgtcZeZlAddSRcdVeHfXwnIteH pu6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e13si5769994pgn.811.2018.01.18.05.40.12; Thu, 18 Jan 2018 05:40:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756249AbeARNjM (ORCPT + 99 others); Thu, 18 Jan 2018 08:39:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43498 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755690AbeARNjL (ORCPT ); Thu, 18 Jan 2018 08:39:11 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D63AF1E2D6; Thu, 18 Jan 2018 13:39:10 +0000 (UTC) Received: from localhost (ovpn-116-192.phx2.redhat.com [10.3.116.192]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7470B60CA9; Thu, 18 Jan 2018 13:39:07 +0000 (UTC) Date: Thu, 18 Jan 2018 08:39:06 -0500 From: Luiz Capitulino To: Chao Fan Cc: , , , , , , , , Subject: Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG] Message-ID: <20180118083906.63df24fa@redhat.com> In-Reply-To: <20180118011113.GA24593@localhost.localdomain> References: <20180117105351.12226-1-fanc.fnst@cn.fujitsu.com> <20180117123235.2276f2e7@redhat.com> <20180118011113.GA24593@localhost.localdomain> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 18 Jan 2018 13:39:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Jan 2018 09:11:14 +0800 Chao Fan wrote: > On Wed, Jan 17, 2018 at 12:32:35PM -0500, Luiz Capitulino wrote: > >On Wed, 17 Jan 2018 18:53:46 +0800 > >Chao Fan wrote: > > > >> ***Background: > >> People reported that kaslr may randomly chooses some positions > >> which are located in movable memory regions. This will break memory > >> hotplug feature. > >> > >> And also on kvm guest with 4GB meory, the good unfragmented 1GB could > >> be occupied by randomized kernel. It will cause hugetlb failing to > >> allocate 1GB page. While kernel with 'nokaslr' has not such issue. > >> This causes regression. Please see the discussion mail: > >> https://lkml.org/lkml/2018/1/4/236 > >> > >> ***Solutions: > >> Introduce a new kernel parameter 'kaslr_mem=nn@ss' to let users to > >> specify the memory regions where kernel can be allowed to randomize > >> safely. > > > >I've tested this series with a 4GB KVM guest. With kaslr_mem=1G, I > >got one 1GB page allocated 100% of the time in 85 boots. Without > >kaslr_mem=, I got 3 failures in only 10 boots (that is, in 3 boots > >I had no 1GB page allocated). > > > >So, this series solves the 1GB page problem for me. > > > > > Thanks for Luiz's test. Btw, my test tested a simple single case, but I think you can add: Tested-by: Luiz Capitulino > > Thanks, > Chao Fan > > >> > >> E.g if 'movable_node' is spedified, we can use 'kaslr_mem=nn@ss' to > >> tell KASLR where we can put kernel safely. Then KASLR code can avoid > >> those movable regions and only choose those immovable regions > >> specified. > >> > >> For hugetlb case, users can always add 'kaslr_mem=1G' in kernel > >> cmdline since the 0~1G is always fragmented region because of BIOS > >> reserved area. Surely users can specify regions more precisely if > >> they know system memory very well. > >> > >> *** Issues need be discussed > >> There are several issues I am not quite sure, please help review and > >> give suggestions: > >> > >> 1) Since there's already mem_avoid[] which stores the memory regions > >> KASLR need avoid. For the regions KASLR can safely use, I name it as > >> mem_usable[], not sure if it's appropriate. Or kaslr_mem[] directly? > >> > >> 2) In v6, I made 'kaslr_mem=' as a kernel parameter which users can use > >> to specify memory regions where kenrel can be extracted safely by > >> 'kaslr_mem=nn@ss', or regions where we need avoid to extract kernel by > >> 'kaslr_mem=nn!ss'. While later I rethink about it, seems > >> 'kaslr_mem=nn@ss' can satisfy the current requirement, there's no need > >> to introduce the 'kaslr_mem=nn!ss'. So I just take that > >> 'kaslr_mem=nn!ss' handling patch off, may add it later if anyone think > >> it's necessary. Any suggestions? > >> https://www.spinics.net/lists/kernel/msg2698457.html > >> > >> ***Test results: > >> - I did some tests for the memory hotplug issues. I specify the memory > >> region in one node, then I found every time the kernel will be > >> extracted to the memory of this node. > >> - Luiz said he will do some tests for the 1G huge page issue. > >> > >> ***History > >> v6->v7: > >> - Drop the unnecessary avoid part for now. > >> - Add document for the new parameter. > >> > >> v5->v6: > >> - Add the last patch to save the avoid memory regions. > >> > >> v4->v5: > >> - Change the problem reported by LKP > >> Follow Dou's suggestion: > >> - Also return if match "movable_node" when parsing kernel commandline > >> in handle_mem_filter without define CONFIG_MEMORY_HOTPLUG > >> > >> v3->v4: > >> Follow Kees's suggestion: > >> - Put the functions variables of immovable_mem to #ifdef > >> CONFIG_MEMORY_HOTPLUG and change some code place > >> - Change the name of "process_mem_region" to "slots_count" > >> - Reanme the new function "process_immovable_mem" to "process_mem_region" > >> Follow Baoquan's suggestion: > >> - Fail KASLR if "movable_node" specified without "immovable_mem" > >> - Ajust the code place of handling mem_region directely if no > >> immovable_mem specified > >> Follow Randy's suggestion: > >> - Change the mistake and add detailed description for the document. > >> > >> v2->v3: > >> Follow Baoquan He's suggestion: > >> - Change names of several functions. > >> - Add a new parameter "immovable_mem" instead of extending mvoable_node > >> - Use the clamp to calculate the memory intersecting, which makes > >> logical more clear. > >> - Disable memory mirror if movable_node specified > >> > >> v1->v2: > >> Follow Dou Liyang's suggestion: > >> - Add the parse for movable_node=nn[KMG] without @ss[KMG] > >> - Fix the bug for more than one "movable_node=" specified > >> - Drop useless variables and use mem_vector region directely > >> - Add more comments. > >> > >> Chao Fan (5): > >> x86/KASLR: Add kaslr_mem=nn[KMG]@ss[KMG] > >> x86/KASLR: Handle the memory regions specified in kaslr_mem > >> x86/KASLR: Give a warning if movable_node specified without kaslr_mem= > >> x86/KASLR: Skip memory mirror handling if movable_node specified > >> document: add document for kaslr_mem > >> > >> Documentation/admin-guide/kernel-parameters.txt | 10 ++ > >> arch/x86/boot/compressed/kaslr.c | 154 +++++++++++++++++++++--- > >> 2 files changed, 150 insertions(+), 14 deletions(-) > >> > > > > > > > >