Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1528276imm; Wed, 1 Aug 2018 18:21:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfrn5/pJ6bhPZ+b7oOlkWquFpweEkfqR9iSMC8T/5xzSvebvafXoSW9i2XcUoRCxgI6kBgD X-Received: by 2002:a63:7252:: with SMTP id c18-v6mr638667pgn.186.1533172917948; Wed, 01 Aug 2018 18:21:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533172917; cv=none; d=google.com; s=arc-20160816; b=BIR1/gvIXNE760WrdnDISM8L7dOrGWfQ57oSttlM2TIS6xMxG0GWwa55SvMkwOI1bM 2YFKFO94kmAS5rTMqra3n1OdpxLM5TaeqQa2ha/SYqm/Dp2rQEWDieT7oDHrV3d0Ip+g zv8R4vUsgkZiS5t433YQVyyxTJ4GIBNpbdp2N0cywDGhU/DqIPHo4TSWO2+2+dS4Trqj NHCyKkX9xEEUL81Ndkmz1wzM65Krdbp8WWD0CVL75oo4+kxqMc1cCXbnPL0Nt1RSmjYk d6ipHBf/Sph8YQpaHmYeZZWm1yroLmJqpRiXP57LuGKxw3tQo9wA+RsZxYps0AGF4F27 93tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=IBrLu+QJGmWuwwzduXLbHOM5PkWV1Oheuta3mhhmIPo=; b=KnXIRfkJdapXuhfhuxzdvl9qT8jqvZPLJsUAEe2QqyjgYLVgzLJ7mcI+hrq9tlgNgb VPJYrIPVL2gPtpxooaiJKVUQ6Vz028U7Q41M+VJRiMZuacC49UPKkmBZLL3PBpVmJH63 ug5TlxSVKwp9jA7w9biV/UTIU3EMiyveZsjQMVmU52hRUNIxXVwq2U3plspVwzfZ5w68 TsFOjsc0BSc5dPllR+m4+2+JM7uwpNbK1qZPiPNxtbtxZGQqleFlIPT3x136cxitNcg8 YR89/aRrtBYZBu5pD7vObJ9NVZfbUQHP90eoIfpK7eQX+Q5iF9+qC0nT2VCLuHM4GPTN t7LQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1-v6si509119pgb.464.2018.08.01.18.21.43; Wed, 01 Aug 2018 18:21:57 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732438AbeHBDIa (ORCPT + 99 others); Wed, 1 Aug 2018 23:08:30 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:31521 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726444AbeHBDI3 (ORCPT ); Wed, 1 Aug 2018 23:08:29 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="42957283" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 02 Aug 2018 09:19:46 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 3EA114B66A09; Thu, 2 Aug 2018 09:19:45 +0800 (CST) Received: from localhost.localdomain (10.167.225.56) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 2 Aug 2018 09:19:49 +0800 Date: Thu, 2 Aug 2018 09:17:36 +0800 From: Chao Fan To: , , , , , , , CC: , , Subject: Re: [PATCH v4 0/4] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory. Message-ID: <20180802011735.GB6723@localhost.localdomain> References: <20180723092908.32656-1-fanc.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20180723092908.32656-1-fanc.fnst@cn.fujitsu.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [10.167.225.56] X-yoursite-MailScanner-ID: 3EA114B66A09.AA06A X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: fanc.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Sorry for disturbance, no reply for a week, any comments? Thanks, Chao Fan On Mon, Jul 23, 2018 at 05:29:04PM +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 make the memory can't be removed. > >***Solutions: >There should be a method to limit kaslr to choosing immovable memory >regions, so there are 2 solutions: >1) Add a kernel parameter to specify the memory regions. >2) Get the information of memory hotremove, then kaslr will know the > right regions. >In method 2, information about memory hot remove is in ACPI >tables, which will be parsed after 'start_kernel', kaslr can't get >the information. >In method 1, users should know the regions address and specify in >kernel parameter. > >In the earliest time, I tried to dig ACPI tabls to solve this problem. >But I didn't splite the code in 'compressed/' and ACPI code, so the patch >is hard to follow so refused by community. >Somebody suggest to add a kernel parameter to specify the >immovable memory so that limit kaslr in these regions. Then I make >a patchset. After several versions, Ingo gave a suggestion: >https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1634024.html >Follow Ingo's suggestion, imitate the ACPI code to parse the acpi >tables, so that the kaslr can get necessary memory information in >ACPI tables. >Since I think ACPI code is independent part, so copy the codes >and functions to 'compressed/' directory, so that kaslr won't >influence the initialization of ACPI. > >PATCH 1/4 Reuse the head file of linux/acpi.h, and copy a fcuntion from > ACPI code. >PATCH 2/4 Functions to parse ACPI code. >PATCH 3/4 If 'CONFIG_MEMORY_HOTREMOVE' specified, walk all nodes and > store the information of immovable memory regions. >PATCH 4/4 According to the immovable memory regions, filter the > immovable regions which KASLR can choose. > >***Test results: > - I did a very simple test, and it can get the memory information in > bios and efi KVM guest machine, and put it by early printk. But no > more tests, so it's with RFC tag. > >v1->v2: > - Simplify some code. >Follow Baoquan He's suggestion: > - Reuse the head file of acpi code. > >v2->v3: > - Test in more conditions, so remove the 'RFC' tag. > - Change some comments. > >v3->v4: >Follow Thomas Gleixner's suggetsion: > - Put the whole efi related function into #define CONFIG_EFI and return > false in the other stub. > - Simplify two functions in head file. > >Any comments will be welcome. > > >Chao Fan (4): > x86/boot: Add acpitb.h to help parse acpi tables > x86/boot: Add acpitb.c to parse acpi tables > x86/boot/KASLR: Walk srat tables to filter immovable memory > x86/boot/KASLR: Limit kaslr to choosing the immovable memory > > arch/x86/boot/compressed/Makefile | 4 + > arch/x86/boot/compressed/acpitb.c | 251 ++++++++++++++++++++++++++++++ > arch/x86/boot/compressed/acpitb.h | 7 + > arch/x86/boot/compressed/kaslr.c | 121 ++++++++++++-- > 4 files changed, 372 insertions(+), 11 deletions(-) > create mode 100644 arch/x86/boot/compressed/acpitb.c > create mode 100644 arch/x86/boot/compressed/acpitb.h > >-- >2.17.1 >