Received: by 10.223.148.5 with SMTP id 5csp6115012wrq; Wed, 17 Jan 2018 09:33:24 -0800 (PST) X-Google-Smtp-Source: ACJfBouYvMu56z1sIXMDid22e7bb8GtxyKpAoRPdOSOB9CdN1VNr2Tv8oaWwDmPptR7EYQsu8xIg X-Received: by 10.84.247.143 with SMTP id o15mr42654061pll.98.1516210404340; Wed, 17 Jan 2018 09:33:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516210404; cv=none; d=google.com; s=arc-20160816; b=T4kLbmZ1MifI5CcbucEXdbECyvnGF2vySqFvuDOi0uaWoP6AVpzg5n7dqCqWRMuCJr 7CrBqxm0RyPNZpOsLWi9Hky3wWzibGAHZaceSBKss+U+V30vwWbEr68a3vOfwMcbWaMb jVGohKh/GvPlh+zKzHPkatc16PT2nAOFS0g4be1spSI4trzmKSphu4RpAxxqoRrXK/Gb MLrKShRMFinc5O5UIozQujQUDfyGwCL55TcpYU5GnD9b/OhZQ7dPz7IUjp3UlrmN63Q1 Vqt+ZB5iS4RaqkbzOGOR+swKQiZ0Qktly8aHO3JWm7lsVkTk6BI91nWFd+ruMfqRYIlg KHsA== 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=x4GgfU56u/Q8waZgniqyM9x4A/+yIaZ6b3O6DSOHHLg=; b=b9MabGszmKLKAH7MYMZHUCyr7mS+bIyvQWB5AXD49Xb5kIfTCrQO2fojKOm6iZM54V 9GpQ+Uo3jJfar1BcofnrZIYxkAa3AGDHYpZQtdn17SjX4bs+deEDApNrv56r/YXbaGEa heFr20//xclCdy72RSQYG5jtqse5Z9uqFHINGd8D4vC7YO1HWHwQaU/TUyKzOmbugpYW HZWvBAoVBeM5ACwrcddsUpYrpOFLWv/ki3EsTKiU+MHGFzPBp7qyh/7UkFDRKzCCKH2M V+a+NMjJzheQWWwQKR/cXlgB2OGY08cekUbJNMkczyFypHJcKZdcc/6c2BCcWMwtBAEW 1SqA== 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 p16si4912560plr.191.2018.01.17.09.33.09; Wed, 17 Jan 2018 09:33:24 -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 S1754135AbeAQRcl (ORCPT + 99 others); Wed, 17 Jan 2018 12:32:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48056 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906AbeAQRci (ORCPT ); Wed, 17 Jan 2018 12:32:38 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5380782109; Wed, 17 Jan 2018 17:32:38 +0000 (UTC) Received: from localhost (ovpn-116-192.phx2.redhat.com [10.3.116.192]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0EA7161F2A; Wed, 17 Jan 2018 17:32:35 +0000 (UTC) Date: Wed, 17 Jan 2018 12:32:35 -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: <20180117123235.2276f2e7@redhat.com> In-Reply-To: <20180117105351.12226-1-fanc.fnst@cn.fujitsu.com> References: <20180117105351.12226-1-fanc.fnst@cn.fujitsu.com> 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 17 Jan 2018 17:32:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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(-) >