linux-kernel - Re: [PATCH v7 1/3] efi/x86: Fix EFI memory map corruption with kexec

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: Wed, 5 Jun 2024 13:15:27 +0200
From: Borislav Petkov <bp@...en8.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Dave Young <dyoung@...hat.com>, Mike Rapoport <rppt@...nel.org>,
	"Kalra, Ashish" <ashish.kalra@....com>, tglx@...utronix.de,
	mingo@...hat.com, dave.hansen@...ux.intel.com, x86@...nel.org,
	rafael@...nel.org, hpa@...or.com, peterz@...radead.org,
	adrian.hunter@...el.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
	jun.nakajima@...el.com, rick.p.edgecombe@...el.com,
	thomas.lendacky@....com, michael.roth@....com, seanjc@...gle.com,
	kai.huang@...el.com, bhe@...hat.com,
	kirill.shutemov@...ux.intel.com, bdas@...hat.com,
	vkuznets@...hat.com, dionnaglaze@...gle.com, anisinha@...hat.com,
	jroedel@...e.de, kexec@...ts.infradead.org,
	linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/3] efi/x86: Fix EFI memory map corruption with kexec

On Wed, Jun 05, 2024 at 10:17:22AM +0200, Ard Biesheuvel wrote:
> I'd argue for the opposite: ideally, the difference between the first
> boot and not-the-first-boot should be abstracted away by the
> 'bootloader' side of kexec as much as possible, so that the tricky
> early startup code doesn't have to be riddled with different code
> paths depending on !kexec vs kexec.

Well, off and on we end up needing to be able to ask whether the current
kernel is kexec-ed. So you need to be able to access that aspect in
kernel code - not in the bootloader. Perhaps read it from the
bootloader, sure.

But see my other mail from just now - it might end up not needing it
after all and I'd prefer if we never ever have to ask that question but
just from staring at EFI code it reminded me that we do need to ask that
question already:

        if (efi_setup)
                kexec_enter_virtual_mode();
        else
                __efi_enter_virtual_mode();

*exactly* because of EFI and that virtual_map call nonsense of allowing
it only once.

And we check efi_setup here because that works. But you can't use that
globally. And so on...

> TDX is a good case in point here: rather than add more conditionals,
> I'd urge to remove them so the TDX startup code doesn't have to care
> about the difference at all. If there is anything special that needs
> to be done, it belongs in the kexec implementation of the previous
> kernel.

Sure, but reality is not as easy sometimes.

Thx.

-- 
Regards/Gruss,
    Boris.

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