linux-kernel - Re: [PATCH] x86/efi: Do not release sub-1MB memory regions when the crashkernel option is specified

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <8FAA2A0E-0A09-4308-B936-CDD2C0568BAE@amacapital.net>
Date:   Sun, 11 Apr 2021 18:49:12 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Baoquan He <bhe@...hat.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>,
        Lianbo Jiang <lijiang@...hat.com>,
        linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, x86@...nel.org,
        ardb@...nel.org, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dvhart@...radead.org, andy@...radead.org,
        kexec@...ts.infradead.org, dyoung@...hat.com
Subject: Re: [PATCH] x86/efi: Do not release sub-1MB memory regions when the crashkernel option is specified

> On Apr 11, 2021, at 6:14 PM, Baoquan He <bhe@...hat.com> wrote:
> 
> On 04/09/21 at 07:59pm, H. Peter Anvin wrote:
>> Why don't we do this unconditionally? At the very best we gain half a megabyte of memory (except the trampoline, which has to live there, but it is only a few kilobytes.)
> 
> This is a great suggestion, thanks. I think we can fix it in this way to
> make code simpler. Then the specific caring of real mode in
> efi_free_boot_services() can be removed too.
> 

This whole situation makes me think that the code is buggy before and buggy after.

The issue here (I think) is that various pieces of code want to reserve specific pieces of otherwise-available low memory for their own nefarious uses. I don’t know *why* crash kernel needs this, but that doesn’t matter too much.

I propose that the right solution is to give low-memory-reserving code paths two chances to do what they need: once at the very beginning and once after EFI boot services are freed.

Alternatively, just reserve *all* otherwise unused sub 1M memory up front, then release it right after releasing boot services, and then invoke the special cases exactly once.

In either case, the result is that the crashkernel mess gets unified with the trampoline mess.  One way the result is called twice and needs to be more careful, and the other way it’s called only once.

Just skipping freeing boot services seems wrong.  It doesn’t unmap boot services, and skipping that is incorrect, I think. And it seems to result in a bogus memory map in which the system thinks that some crashkernel memory is EFI memory instead.

Let’s please just fix the problem instead of papering over it with more hacks.

> Thanks
> Baoquan
>