[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180925011246.GB12561@localhost.localdomain>
Date: Tue, 25 Sep 2018 09:12:46 +0800
From: Chao Fan <fanc.fnst@...fujitsu.com>
To: Kees Cook <keescook@...omium.org>
CC: linux-efi <linux-efi@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
<indou.takao@...fujitsu.com>, <caoj.fnst@...fujitsu.com>
Subject: Re: [PATCH v7 1/3] x86/boot: Add acpitb.c to parse acpi tables
On Sat, Sep 22, 2018 at 08:45:12AM -0700, Kees Cook wrote:
>On Thu, Sep 13, 2018 at 3:46 AM, Chao Fan <fanc.fnst@...fujitsu.com> wrote:
>> There is a bug that kaslr may randomly chooses some positions
>> which are located in movable memory regions. This will break memory
>> hotplug feature and make the movable memory chosen by KASLR can't be
>> removed. So dig SRAT table from ACPI tables to get memory information.
>>
>> Imitate the ACPI code of parsing ACPI tables to dig and read ACPI
>> tables. Since some operations are not needed here, functions are
>> simplified. Functions will be used to dig only SRAT tables to get
>> information of memory, so that KASLR can the memory in immovable node.
>>
>> And also, these functions won't influence the initialization of
>> ACPI after start_kernel().
>>
>> Since use physical address directely, so acpi_os_map_memory()
>> and acpi_os_unmap_memory() are not needed.
>>
>> Signed-off-by: Chao Fan <fanc.fnst@...fujitsu.com>
>> ---
>> arch/x86/boot/compressed/Makefile | 4 +
>> arch/x86/boot/compressed/acpitb.c | 401 ++++++++++++++++++++++++++++++
>
>Does this logic live anywhere else in the kernel already? (i.e. could
>other code be reused?)
Live in uncompressec period, but not completely same.
The map between physical address and virtual address is not needed here.
So I thins it's hard to reuse, that's why I made this new file.
Thanks,
Chao Fan
>
>-Kees
>
>--
>Kees Cook
>Pixel Security
>
>
Powered by blists - more mailing lists