linux-kernel - Re: [PATCH 1/3] x86/setup: always reserve the first 1M of RAM

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]

Date:   Thu, 3 Jun 2021 19:57:36 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...capital.net>,
        Andy Shevchenko <andy@...radead.org>,
        Ard Biesheuvel <ardb@...nel.org>, Baoquan He <bhe@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Dave Young <dyoung@...hat.com>,
        Hugh Dickins <hughd@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Lianbo Jiang <lijiang@...hat.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-doc@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/3] x86/setup: always reserve the first 1M of RAM

On Tue, Jun 01, 2021 at 10:53:52AM +0300, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@...ux.ibm.com>
> 
> There are BIOSes that are known to corrupt the memory under 1M, or more
> precisely under 640K because the memory above 640K is anyway reserved for
> the EGA/VGA frame buffer and BIOS.
> 
> To prevent usage of the memory that will be potentially clobbered by the
> kernel, the beginning of the memory is always reserved. The exact size of
> the reserved area is determined by CONFIG_X86_RESERVE_LOW build time and
> reservelow command line option. The reserved range may be from 4K to 640K
> with the default of 64K. There are also configurations that reserve the
> entire 1M range, like machines with SandyBridge graphic devices or systems
> that enable crash kernel.
> 
> In addition to the potentially clobbered memory, EBDA of unknown size may
> be as low as 128K and the memory above that EBDA start is also reserved
> early.
> 
> It would have been possible to reserve the entire range under 1M unless for
> the real mode trampoline that must reside in that area.
> 
> To accommodate placement of the real mode trampoline and keep the memory
> safe from being clobbered by BIOS reserve the first 64K of RAM before
> memory allocations are possible and then, after the real mode trampoline is
> allocated, reserve the entire range from 0 to 1M.
> 
> Update trim_snb_memory() and reserve_real_mode() to avoid redundant
> reservations of the same memory range.
> 
> Also make sure the memory under 1M is not getting freed by
> efi_free_boot_services().
> 
> Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> Signed-off-by: Mike Rapoport <rppt@...ux.ibm.com>
> ---
>  arch/x86/kernel/setup.c        | 35 ++++++++++++++++++++--------------
>  arch/x86/platform/efi/quirks.c | 12 ++++++++++++
>  arch/x86/realmode/init.c       | 14 ++++++++------
>  3 files changed, 41 insertions(+), 20 deletions(-)

Ok, let's try it. Booting on a couple of boxes looks ok here, the
difference is visible:

-  DMA zone: 30 pages reserved
+  DMA zone: 159 pages reserved

On the other box, it was already reserving so many pages even before

  DMA zone: 159 pages reserved

i.e., the first 640K.

But it's not like I had problems before with early reservations so my
testing doesn't mean a whole lot. Hugh's testing sounds good, lemme add
his tag too.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette