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

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

Message-ID: <CAMj1kXFweoskB_qnUFA1b+QXWhjovwMfpM00cGb9KMcm4Zr7EA@mail.gmail.com>
Date: Wed, 5 Jun 2024 10:17:22 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
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, 5 Jun 2024 at 09:43, Borislav Petkov <bp@...en8.de> wrote:
>
> On Wed, Jun 05, 2024 at 10:53:44AM +0800, Dave Young wrote:
> > It's something good to have but not must for the time being,  also no
> > idea how to save the status across boot, for EFI boot case probably a
> > EFI var can be used;
>
> Yes.
>
> > but how can it be cleared in case of physical boot.  Otherwise
> > probably injecting some kernel parameters, anyway this needs more
> > thinking.
>
> Yeah, this'll need proper analysis whether we can even do that reliably.
>
> We need to increment it only on the kexec reboot paths and clear it on
> the normal reboot paths.
>

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.

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.