From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Fan Subject: Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory Date: Thu, 11 Oct 2018 13:51:54 +0800 Message-ID: <20181011055154.GB6667@localhost.localdomain> References: <20181010084119.17539-1-fanc.fnst@cn.fujitsu.com> <20181010085920.GB5533@zn.tnic> <20181010090620.GF25297@MiWiFi-R3L-srv> <20181010091923.GC5533@zn.tnic> <20181010093057.GA22088@MiWiFi-R3L-srv> <20181010194443.sgdvplwdnltshwwi@gabell> <20181011002955.GJ25297@MiWiFi-R3L-srv> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: <20181011002955.GJ25297@MiWiFi-R3L-srv> Sender: linux-kernel-owner@vger.kernel.org To: Baoquan He Cc: Masayoshi Mizuma , Borislav Petkov , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org, linux-efi@vger.kernel.org, linux-acpi@vger.kernel.org, mingo@redhat.com, hpa@zytor.com, keescook@chromium.org, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org, indou.takao@jp.fujitsu.com, caoj.fnst@cn.fujitsu.com List-Id: linux-acpi@vger.kernel.org On Thu, Oct 11, 2018 at 08:29:55AM +0800, Baoquan He wrote: >On 10/10/18 at 03:44pm, Masayoshi Mizuma wrote: >> On Wed, Oct 10, 2018 at 05:30:57PM +0800, Baoquan He wrote: >> > On 10/10/18 at 11:19am, Borislav Petkov wrote: >> > > On Wed, Oct 10, 2018 at 11:14:26AM +0200, Thomas Gleixner wrote: >> > > > Yes, it's different, but if the SRAT information is available early, then >> > > > the command line parameter can go away because then the required >> > > > information for Masa's problem is available as well. >> > > >> > > Exactly. And I'd prefer we delayed the command line parameter until we >> > > figure out we really need it and not expose it to upstream and then >> > > remove it shortly after. >> > > >> > > So I'd suggest we move Masa's patches to a separate branch and not send >> > > it up this round. >> > >> > Yes, sounds more reasonable if we can reuse functions in Chao's patch 1/3 >> > to solve the padding issue. >> >> Thanks for your comments! Yes, immovable_mem[num_immovable_mem] in Chao's >> patch may be useful for calculating the padding size. If so, we don't >> need the new kernel parameter. It's nice! >> >> Do you happen to have ideas how we access immovable_mem[num_immovable_mem] >> from arch/x86/mm/kaslr.c ? It is located to arch/x86/boot/compressed/*, so >> I suppose it is not easy to access it... >> I would appreciate if you could give some advice. > >Hmm, they are living in different life cycle and space. So we can only >reuse the code from Chao's patch, but not the variable. Means we need >go through the SRAT accessing again in arch/x86/mm/kaslr.c and fill >immovable_mem[num_immovable_mem] for mm/kaslr.c usage, if we decide to >do like that. Reading three times is redundant, but reading two times is needed. Becasue the ACPI code run very stable, but we need more information before that. As for Masa's issue, I am wondering whether we can tranfer the information or only the address of SRAT table from compressed period to the period after start_kernel(). Thanks, Chao Fan > >Thanks >Baoquan > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C86BC32788 for ; Thu, 11 Oct 2018 05:52:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 253C321470 for ; Thu, 11 Oct 2018 05:52:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 253C321470 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cn.fujitsu.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728015AbeJKNSS (ORCPT ); Thu, 11 Oct 2018 09:18:18 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:7730 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727529AbeJKNSR (ORCPT ); Thu, 11 Oct 2018 09:18:17 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="45914224" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 11 Oct 2018 13:52:32 +0800 Received: from G08CNEXCHPEKD01.g08.fujitsu.local (unknown [10.167.33.80]) by cn.fujitsu.com (Postfix) with ESMTP id 0F56B4B6ED95; Thu, 11 Oct 2018 13:52:34 +0800 (CST) Received: from localhost.localdomain (10.167.225.56) by G08CNEXCHPEKD01.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Oct 2018 13:52:39 +0800 Date: Thu, 11 Oct 2018 13:51:54 +0800 From: Chao Fan To: Baoquan He CC: Masayoshi Mizuma , Borislav Petkov , Thomas Gleixner , Ingo Molnar , , , , , , , , , , , , Subject: Re: [PATCH v8 0/3] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory Message-ID: <20181011055154.GB6667@localhost.localdomain> References: <20181010084119.17539-1-fanc.fnst@cn.fujitsu.com> <20181010085920.GB5533@zn.tnic> <20181010090620.GF25297@MiWiFi-R3L-srv> <20181010091923.GC5533@zn.tnic> <20181010093057.GA22088@MiWiFi-R3L-srv> <20181010194443.sgdvplwdnltshwwi@gabell> <20181011002955.GJ25297@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20181011002955.GJ25297@MiWiFi-R3L-srv> User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [10.167.225.56] X-yoursite-MailScanner-ID: 0F56B4B6ED95.AE540 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: fanc.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 11, 2018 at 08:29:55AM +0800, Baoquan He wrote: >On 10/10/18 at 03:44pm, Masayoshi Mizuma wrote: >> On Wed, Oct 10, 2018 at 05:30:57PM +0800, Baoquan He wrote: >> > On 10/10/18 at 11:19am, Borislav Petkov wrote: >> > > On Wed, Oct 10, 2018 at 11:14:26AM +0200, Thomas Gleixner wrote: >> > > > Yes, it's different, but if the SRAT information is available early, then >> > > > the command line parameter can go away because then the required >> > > > information for Masa's problem is available as well. >> > > >> > > Exactly. And I'd prefer we delayed the command line parameter until we >> > > figure out we really need it and not expose it to upstream and then >> > > remove it shortly after. >> > > >> > > So I'd suggest we move Masa's patches to a separate branch and not send >> > > it up this round. >> > >> > Yes, sounds more reasonable if we can reuse functions in Chao's patch 1/3 >> > to solve the padding issue. >> >> Thanks for your comments! Yes, immovable_mem[num_immovable_mem] in Chao's >> patch may be useful for calculating the padding size. If so, we don't >> need the new kernel parameter. It's nice! >> >> Do you happen to have ideas how we access immovable_mem[num_immovable_mem] >> from arch/x86/mm/kaslr.c ? It is located to arch/x86/boot/compressed/*, so >> I suppose it is not easy to access it... >> I would appreciate if you could give some advice. > >Hmm, they are living in different life cycle and space. So we can only >reuse the code from Chao's patch, but not the variable. Means we need >go through the SRAT accessing again in arch/x86/mm/kaslr.c and fill >immovable_mem[num_immovable_mem] for mm/kaslr.c usage, if we decide to >do like that. Reading three times is redundant, but reading two times is needed. Becasue the ACPI code run very stable, but we need more information before that. As for Masa's issue, I am wondering whether we can tranfer the information or only the address of SRAT table from compressed period to the period after start_kernel(). Thanks, Chao Fan > >Thanks >Baoquan > >