linux-kernel - Re: [tip: x86/urgent] 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]

Message-Id: <840dcfd4-0d6c-400a-9cf7-8fe56d55ac7f@app.fastmail.com>
Date:   Thu, 02 Mar 2023 07:06:11 -0800
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Borislav Petkov" <bp@...en8.de>
Cc:     "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Mike Rapoport" <rppt@...ux.ibm.com>,
        "Hugh Dickins" <hughd@...gle.com>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [tip: x86/urgent] x86/setup: Always reserve the first 1M of RAM



On Thu, Mar 2, 2023, at 2:50 AM, Borislav Petkov wrote:
> On Wed, Mar 01, 2023 at 07:51:43PM -0800, Andy Lutomirski wrote:
>> This is quite broken.  The comments in the patch seem to understand
>> that Linux tries twice to allocate the real mode trampoline, but the
>> code has some issues.
>> 
>> First, it actively breaks the logic here:
>> 
>> +               /*
>> +                * Don't free memory under 1M for two reasons:
>> +                * - BIOS might clobber it
>> +                * - Crash kernel needs it to be reserved
>> +                */
>> +               if (start + size < SZ_1M)
>> +                       continue;
>> +               if (start < SZ_1M) {
>> +                       size -= (SZ_1M - start);
>> +                       start = SZ_1M;
>> +               }
>> +
>
> Are you refering, per-chance, here to your comment in that same function
> a bit higher?
>
> Introduced by this thing here:
>
> 5bc653b73182 ("x86/efi: Allocate a trampoline if needed in 
> efi_free_boot_services()")
>
> ?

Yes.

>
> Also, it looks like Mike did pay attention to your commit:
>
> https://lore.kernel.org/all/YLZsEaimyAe0x6b3@kernel.org/

He definitely did.  But I'm still pretty sure the patch in question broke it :-/

>
> And then there's the whole deal with kdump kernel needing lowmem. The
> function which became obsolete and got removed by:
>
> 23721c8e92f7 ("x86/crash: Remove crash_reserve_low_1M()")
>
> So, considering how yours is the only report that breaks booting and
> this reservation of <=1M has been out there for ~2 years without any
> complaints, I'm thinking what we should do now is fix that logic.
>
> Btw, this whole effort started with
>
>   a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
>
> Also see this:
>
> ec35d1d93bf8 ("x86/setup: Document that Windows reserves the first MiB")
>
> and with shit like that, we're "piggybacking" on Windoze since there
> certification happens at least.
>
> Which begs the question: how does your laptop even boot on windoze if
> windoze reserves that 1M too?!

I haven't booted Windoze on this thing in years.  But...

There is no possible way that Windoze genuinely reserves the first 1M. It does SMP, and x86 needs <1M memory for SMP, so Windoze uses <1M memory.  QED :)

>
>> I real the commit message and the linked bug, and I'm having trouble
>> finding evidence of anything actually fixed by this patch.  Can we
>> just revert it?  If not, it would be nice to get a fixup patch that
>> genuinely cleans this up -- the whole structure of the code (first,
>> try to allocate trampoline, then free boot services, then try again)
>> isn't really conducive to a model where we *don't* free boot services
>> < 1M.
>
> Yes, I think this makes most sense. And that whole area is a minefield
> so the less we upset the current universe, the better.

I'll send a revert patch.

Thinking about this a bit more, if we actually want to "reserve" <1M, we should implement it completely differently by treating <1M as its very own special thing and teaching the memblock allocator to refuse to allocate <1M unless specifically requested.  There's only a very small number of allocations that need it (crashkernel for some reason?), and there are at least two spurious users of memblock_phys_alloc_range that curently may use <1M but have no business doing so (ramdisk code and the NUMA distance table).  But let's only do that if there's an actual problem to solve.

>
>> Discovered by my delightful laptop, which does not boot with this patch applied.
>
> How come your laptop hasn't booted new Linux since then?!? Tztztztz

Honestly, no clue.  Looking at the logs, I'm pretty sure I *did* boot an affected (6.0) kernel.  The actual problematic memory map on this laptop seems to show up a bit inconsistently as some horrible combination of firmware settings (especially SGX) and who-knows-what else.  My best guess is that a GRUB update I installed yesterday caused some tiny memory map change that triggered it.

I did install a new kernel yesterday too, but the *previous* kernel stopped booting too.

>
> Thx.
>
> -- 
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette