From: Kiryl Shutsemau <kirill@shutemov.name>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
Ard Biesheuvel <ardb+git@google.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Mailhol <mailhol@kernel.org>,
x86@kernel.org
Subject: Re: [PATCH v2 01/10] x86/boot: Drop pointless re-implementation of panic()
Date: Thu, 10 Sep 2026 14:12:23 +0100 [thread overview]
Message-ID: <aqKrhNQ3mZMs5-Dy@thinkstation> (raw)
In-Reply-To: <cee2e02b-3817-44cf-857f-62a148290367@app.fastmail.com>
On Wed, Sep 09, 2026 at 10:43:23PM +0200, Ard Biesheuvel wrote:
>
> On Wed, 9 Sep 2026, at 21:14, Borislav Petkov wrote:
> > On Wed, Sep 09, 2026 at 01:55:32PM +0200, Ard Biesheuvel wrote:
> >> From: Ard Biesheuvel <ardb@kernel.org>
> >>
> >> The decompressor has its own implementation of panic(), which is based
> >> on the vsnprintf() routine provided by the EFI stub.
> >>
> >> Relying on the EFI stub from code that does not execute in the context
> >> of the EFI boot services is a bad idea. It is also completely pointless
> >> in this case, given that the only user of this version of panic() only
> >> passes a compile time constant string, without any printf conversions.
> >>
> >> So use error() instead of panic() in that case, and drop the panic()
> >> implementation entirely. This is needed so that the EFI stub's
> >> vsnprintf() can be modified in a manner that is incompatible with the
> >> expectations of this caller.
> >>
> >> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >> ---
> >> arch/x86/boot/compressed/error.c | 19 -------------------
> >> arch/x86/boot/compressed/error.h | 1 -
> >> arch/x86/boot/compressed/mem.c | 2 +-
> >> 3 files changed, 1 insertion(+), 21 deletions(-)
> >>
> >> diff --git a/arch/x86/boot/compressed/error.c b/arch/x86/boot/compressed/error.c
> >> index 19a8251de506..ce5ed7d8265e 100644
> >> --- a/arch/x86/boot/compressed/error.c
> >> +++ b/arch/x86/boot/compressed/error.c
> >> @@ -22,22 +22,3 @@ void error(char *m)
> >> while (1)
> >> asm("hlt");
> >> }
> >> -
> >> -/* EFI libstub provides vsnprintf() */
> >> -#ifdef CONFIG_EFI_STUB
> >> -void panic(const char *fmt, ...)
> >
> > So this thing appeared magically in v8 of the TDX unaccepted memory patches
> > and I don't think we questioned it back then.
> >
> > v7's tdx_accept_memory() does error():
> >
> > https://lore.kernel.org/all/20220614120231.48165-15-kirill.shutemov@linux.intel.com/
> >
> > and v8 started doing panic():
> >
> > +void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > + if (!tdx_enc_status_changed_phys(start, end, true))
> > + panic("Accepting memory failed: %#llx-%#llx\n", start, end);
> > +}
> >
> > https://lore.kernel.org/all/20221207014933.8435-15-kirill.shutemov@linux.intel.com/
> >
> > and it switched to it being a vsnprintf() wrapper because it wanted to dump
> > start and end perhaps.
> >
> > But then it ended up dropping the params in v13 and landed upstream with
> > a single string as an argument.
> >
> > Anyway, adding Kiryl/Kirill for comment and leaving in the rest for reference.
> >
>
> Looking at that v13, it seems the panic() call was added to
> arch/x86/coco/tdx/tdx-shared.c, which was shared between the kernel proper and
> the decompressorat the time, and so a panic() implementation was needed in the
> decompressor too. But that is no longer the case.
Right. I don't mind dropping this panic() from the decompressor. The
range was already gone since v13 and I never saw the error trigger
anyway.
Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-09-10 13:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 11:55 [PATCH v2 00/10] efi/libstub: Avoid UTF-16 conversion busywork Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 01/10] x86/boot: Drop pointless re-implementation of panic() Ard Biesheuvel
2026-09-09 19:14 ` Borislav Petkov
2026-09-09 20:43 ` Ard Biesheuvel
2026-09-10 13:12 ` Kiryl Shutsemau [this message]
2026-09-11 7:32 ` Ard Biesheuvel
2026-09-12 6:10 ` Borislav Petkov
2026-09-12 8:41 ` Ard Biesheuvel
2026-09-12 17:54 ` Borislav Petkov
2026-09-13 16:35 ` Ard Biesheuvel
2026-09-13 18:11 ` Borislav Petkov
2026-09-09 11:55 ` [PATCH v2 02/10] lib/ucs2_string: Drop arbitrary input size limit and associated WARN() Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 03/10] lib/ucs2_string: Suppress modinfo when __DISABLE_EXPORTS is set Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 04/10] lib/ucs2_string: Split out ucs2_as_utf8_l() taking a separate limit Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 05/10] efi/libstub: Use ucs2_string library for UTF-16 to UTF-8 conversion Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 06/10] efi/libstub: Avoid efi_puts() for compile time constant strings Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 07/10] efi/libstub: Output UTF-16 directly from vsnprintf() Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 08/10] efi/libstub: Add support for printing human readable GUIDs Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 09/10] efi/libstub: Add efi_snprintf() to construct wide strings Ard Biesheuvel
2026-09-09 11:55 ` [PATCH v2 10/10] efi/libstub: add initial Boot Loader Interface support Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqKrhNQ3mZMs5-Dy@thinkstation \
--to=kirill@shutemov.name \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.