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: <CAMj1kXG8hZ86BFbar9S5mmvKMH4a0XF0oCm36WwZxYNqc0+pjQ@mail.gmail.com>
Date: Mon, 8 Jul 2024 20:17:43 +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 Mon, 8 Jul 2024 at 20:12, Borislav Petkov <bp@...en8.de> wrote:
>
> On Mon, Jul 08, 2024 at 10:42:47AM -0500, Steve Wahl wrote:
> > So I looked at the code more closely, and I don't think boot_page_fault is
> > going to work prior to the call to initialize_identity_maps.  In the current
> > flow in head_64.S, that comes after load_stage2_idt, where here we were
> > trying to use it just after load_stage1_idt, quite a bit earlier.
>
> But still after setting up the #PF handlers in both cases. So it can't be
> that.
>
> > Is there a reason you want to avoid having these areas already entered
> > in the identity map setup by kexec?
>
> Well, imagine my one-liner worked. Can you think of a reason then?
>
> So, theoretically, this should be reproducible in a VM too, I'd say. If we
> could manage to get that EFI config table placed at the right address, to be
> outside of a 1G page so that it doesn't get covered by a Gb mapping.
>
> Or use "nogbpages" and then maybe perhaps with Ard's help hack up OVMF to do
> so. :)
>
> So, can someone with such a box boot with "efi=debug" on the kernel cmdline so
> that we can try to reproduce the memory layout in a VM?
>

Happy to assist, but I'm not sure I follow the approach here.

In the context of a confidential VM, I don't think the page fault
handler is ever an acceptable approach. kexec should filter out config
tables that it doesn't recognize, and map the ones that it does (note
that EFI config tables have no standardized header with a length, so
mapping tables it does *not* recognize is not feasible to begin with).

All these games with on-demand paging may have made sense for 64-bit
kernels booting in 32-bit mode (which can only map the first 4G of
RAM), but in a confiidential VM context with measurement/attestation
etc I think the cure is worse than the disease.