lkml.org 
[lkml]   [2023]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-27 00:42    [W:0.078 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site