linux-kernel - Re: [GIT PULL] x86/urgent for v5.13-rc5

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:   Sun, 6 Jun 2021 23:58:29 +0300
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Borislav Petkov <bp@...e.de>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/urgent for v5.13-rc5

On Sun, Jun 06, 2021 at 12:38:32PM -0700, Linus Torvalds wrote:
> On Sun, Jun 6, 2021 at 12:55 AM Borislav Petkov <bp@...e.de> wrote:
> >
> > - Do away with all the wankery of reserving X amount of memory in
> > the first megabyte to prevent BIOS corrupting it and simply and
> > unconditionally reserve the whole first megabyte.
> 
> This seems a bit draconic.
> 
> How does this work at all under Windows? There must be some windows
> knowledge about what the BIOS updates that we're not aware of.

A while ago hpa said:

	As far as I know, Windows 7 actually reserves all memory below
	1 MiB to avoid BIOS bugs.

(https://bugzilla.kernel.org/show_bug.cgi?id=16661#c2)

> I've pulled it, but it does seem like something odd is going on.
> 
> And that
> 
>     Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations")
> 
> makes me go "Umm.." too. What did a799c2bd29d1 actually break? It
> looks like it was meant to be a no-op consolidation - if somebody
> bisected to it, I think that is a sign that there's something odd
> there.

I also hoped that a799c2bd29d1 would be a no-op consolidation, but I
overlooked that if a user sets CONFIG_X86_RESERVE_LOW or reservelow to 640K
instead of the default 64K, we end up reserving all the memory below 1M
before we allocate the real mode trampoline. This gets even more hairy
because of other things that may also need to reserve the entire first
megabyte, like crash kernel or workaround for Sandy Bridge integrated
graphics bugs.

I believe that reserving everything below 1M after the real mode trampoline
is allocated reduces amount of hidden dependencies and makes things simpler
overall.

-- 
Sincerely yours,
Mike.