linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, catalin.marinas@arm.com,
	will@kernel.org, mark.rutland@arm.com, andersson@kernel.org,
	konradybcio@kernel.org, dmitry.baryshkov@oss.qualcomm.com,
	shivendra.pratap@oss.qualcomm.com,
	leif.lindholm@oss.qualcomm.com, linux-kernel@vger.kernel.org,
	Sumit Garg <sumit.garg@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] arm64: efi: Pass reboot cmd parameter to efi_reboot()
Date: Fri, 14 Nov 2025 17:46:11 +0530	[thread overview]
Message-ID: <aRcdiwgM9h_S7rP-@sumit-X1> (raw)
In-Reply-To: <CAMj1kXE60LrWi8Au6qQ4EMQDFxQCJt5h6hBLuQHCz3HEp=2o3w@mail.gmail.com>

On Fri, Nov 14, 2025 at 10:35:33AM +0100, Ard Biesheuvel wrote:
> On Fri, 14 Nov 2025 at 10:33, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Fri, 14 Nov 2025 at 10:31, Sumit Garg <sumit.garg@kernel.org> wrote:
> > >
> > > On Fri, Nov 14, 2025 at 10:26:03AM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 14 Nov 2025 at 09:51, Sumit Garg <sumit.garg@kernel.org> wrote:
> > > > >
> > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > >
> > > > > EFI ResetSystem runtime service allows for platform specific reset type
> > > > > allowing the OS to pass reset data for the UEFI implementation to take
> > > > > corresponding action. So lets pass the reboot cmd parameter for the EFI
> > > > > driver to determine whether it's a platform specific reset requested or
> > > > > not.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > ---
> > > > >  arch/arm64/kernel/process.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > > > index fba7ca102a8c..51784986c568 100644
> > > > > --- a/arch/arm64/kernel/process.c
> > > > > +++ b/arch/arm64/kernel/process.c
> > > > > @@ -136,7 +136,7 @@ void machine_restart(char *cmd)
> > > > >          * ResetSystem().
> > > > >          */
> > > > >         if (efi_enabled(EFI_RUNTIME_SERVICES))
> > > > > -               efi_reboot(reboot_mode, NULL);
> > > > > +               efi_reboot(reboot_mode, cmd);
> > > > >
> > > >
> > > > I agree with the general principle. However, there are already
> > > > existing callers of kernel_restart() that would end up passing a
> > > > random string to efi_reboot(), resulting in platform specific reset
> > > > with undefined result.
> > >
> > > Yeah true but the UEFI spec says:
> > >
> > > "If the platform does not recognize the EFI_GUID in ResetData the platform
> > > must pick a supported reset type to perform. The platform may optionally
> > > log the parameters from any non-normal reset that occurs."
> > >
> > > So, in these cases the UEFI implementation can fallback to normal reset
> > > optionally logging the reset data being passed. Does that sounds
> > > reasonable to you?
> > >
> >
> > What the UEFI spec says might deviate from how real platforms in the
> > field will behave when being passed a reset type that nobody ever
> > tried passing before.

I suppose from OS point of view, we need to follow the UEFI
specification. However, there will be scope for quirks later if the real
world problems occur. Currently, in case of EFI reboot we are just
ignoring the reboot cmd parameter.

If you have in mind any sanity checks we should do here then feel free
to propose and I can try to implement them.

> 
> Also, the GUID is expected to follow an unbounded NULL terminated
> UTF-16 string in memory, so we could easily cause a crash by doing
> this if \0\0 doesn't appear in the memory following the string.

Okay I see, would following change on top of this patchset address this
concern?

--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -5,6 +5,7 @@
  */
 #include <linux/efi.h>
 #include <linux/reboot.h>
+#include <linux/ucs2_string.h>

 static struct sys_off_handler *efi_sys_off_handler;

@@ -14,11 +15,18 @@ void efi_reboot(enum reboot_mode reboot_mode, const char *data)
 {
        const char *str[] = { "cold", "warm", "shutdown", "platform" };
        int efi_mode, cap_reset_mode;
+       unsigned long reset_data_sz = 0;
+       efi_char16_t *reset_data = NULL;

        if (!efi_rt_services_supported(EFI_RT_SUPPORTED_RESET_SYSTEM))
                return;

        if (data) {
+               reset_data_sz = ucs2_strlen(data) * sizeof(efi_char16_t);
+               reset_data = kzalloc(reset_data_sz + 2, GFP_KERNEL);
+               memcpy(reset_data, data, reset_data_sz);
+               reset_data_sz += 2;
+
                efi_mode = EFI_RESET_PLATFORM_SPECIFIC;
        } else {
                switch (reboot_mode) {
@@ -47,8 +55,7 @@ void efi_reboot(enum reboot_mode reboot_mode, const char *data)
                efi_mode = cap_reset_mode;
        }

-       efi.reset_system(efi_mode, EFI_SUCCESS, sizeof(data),
-                        (efi_char16_t *)data);
+       efi.reset_system(efi_mode, EFI_SUCCESS, reset_data_sz, reset_data);
 }

 bool __weak efi_poweroff_required(void)

-Sumit


  reply	other threads:[~2025-11-14 12:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14  8:50 [PATCH 0/2] efi/reboot: Enable platform specific reset on arm64 Sumit Garg
2025-11-14  8:50 ` [PATCH 1/2] efi/reboot: Add support for EFI_RESET_PLATFORM_SPECIFIC Sumit Garg
2025-11-14 21:39   ` Konrad Dybcio
2025-11-14 21:41   ` Ard Biesheuvel
2025-11-14  8:50 ` [PATCH 2/2] arm64: efi: Pass reboot cmd parameter to efi_reboot() Sumit Garg
2025-11-14  9:26   ` Ard Biesheuvel
2025-11-14  9:31     ` Sumit Garg
2025-11-14  9:33       ` Ard Biesheuvel
2025-11-14  9:35         ` Ard Biesheuvel
2025-11-14 12:16           ` Sumit Garg [this message]
2025-11-14 15:47             ` Ard Biesheuvel
2025-11-17  6:43               ` Sumit Garg

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=aRcdiwgM9h_S7rP-@sumit-X1 \
    --to=sumit.garg@kernel.org \
    --cc=andersson@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=leif.lindholm@oss.qualcomm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=shivendra.pratap@oss.qualcomm.com \
    --cc=sumit.garg@oss.qualcomm.com \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).