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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230302152216.GCZAC/KGPyE9V/rHCK@fat_crate.local>
Date:   Thu, 2 Mar 2023 16:22:16 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Andy Lutomirski <luto@...nel.org>
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 02, 2023 at 07:06:11AM -0800, Andy Lutomirski wrote:
> 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 :)

Then we need to sort this out first. Because this patch says the
contrary.

> >> 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.

I actually replied to the text which spoke about a "fixup patch" - not
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.

No, look at early_reserve_memory(). All kinds of crap use that <1M and
we do special reservations there.

I agree with making it a special region aspect.

-- 
Regards/Gruss,
    Boris.

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