linux-kernel - Re: [PATCH 0/3] Resolve problems with kexec identity mapping

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: <CAMj1kXGsjU5CpF655me1XNA8-5nbk3020vT2Bu5ZoFY25igovg@mail.gmail.com>
Date: Tue, 2 Jul 2024 20:32:22 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Steve Wahl <steve.wahl@....com>, Ashish Kalra <ashish.kalra@....com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
	linux-kernel@...r.kernel.org, Pavin Joseph <me@...injoseph.com>, 
	Eric Hagberg <ehagberg@...il.com>, Simon Horman <horms@...ge.net.au>, 
	Eric Biederman <ebiederm@...ssion.com>, Dave Young <dyoung@...hat.com>, Sarah Brofeldt <srhb@....dk>, 
	Russ Anderson <rja@....com>, Dimitri Sivanich <sivanich@....com>, 
	Hou Wenlong <houwenlong.hwl@...group.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Baoquan He <bhe@...hat.com>, Yuntao Wang <ytcoode@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Joerg Roedel <jroedel@...e.de>, Michael Roth <michael.roth@....com>
Subject: Re: [PATCH 0/3] Resolve problems with kexec identity mapping

On Tue, 2 Jul 2024 at 19:45, Borislav Petkov <bp@...en8.de> wrote:
>
> On Mon, Jul 01, 2024 at 04:27:04PM +0200, Borislav Petkov wrote:
> > On Mon, Jun 24, 2024 at 10:13:44AM -0500, Steve Wahl wrote:
> > > These accesses are a problem because they happen prior to establishing
> > > the page fault interrupt handler that would mend the identity map.  I
> > > know very little about the AMD SEV feature but reading the code I
> > > think it may be required to do this before setting up that handler.
> >
> > Yeah, from looking at it, we should be able to establish a #PF handler that
> > early too but the devil's in the detail, especially in that early boot code.
> >
> > Lemme poke some things and people...
>
> Ard, from EFI perspective and boot services exiting, do you see any potential
> issues if we enable a pagefault handler in load_stage1_idt() in
> arch/x86/boot/compressed/head_64.S already or is the EFI pagetable not really
> "reliable" then?
>

For the first boot, this shouldn't be needed - EFI maps all of RAM so
I wouldn't expect the PF handler to fire, except when writing to code
regions that were mapped ROX by the firmware. But even then, things
should just keep working, although from a security pov, it would be
better if the r/o regions remain r/o

> Would solve the issue in this thread where the EFI config table ends up not
> mapped on some hw configurations, elegantly...
>

The #PF handler makes sense when entering via the 32-bit entrypoint,
where the asm can only map the lower 4G and is in no position to
reason about where RAM lives.

For kexec on a 64-bit system, I would expect the high-level support
code to be capable of simply mapping all of DRAM 1:1, rather than
playing these games with #PF handlers and on-demand mapping.