All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: xen-devel@lists.xenproject.org,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP
Date: Tue, 24 Jun 2025 14:38:25 +0200	[thread overview]
Message-ID: <aFqcQe5quyjhu24P@mail-itl> (raw)
In-Reply-To: <20250624083157.9334-2-frediano.ziglio@cloud.com>

[-- Attachment #1: Type: text/plain, Size: 4506 bytes --]

On Tue, Jun 24, 2025 at 09:31:54AM +0100, Frediano Ziglio wrote:
> A boot loader can load files from outside ESP.
> In these cases device could be not provided or path could
> be something not supported.
> In these cases allows to boot anyway, all information
> could be provided using UKI or using other boot loader
> features.
> 
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> ---
>  xen/common/efi/boot.c | 27 +++++++++++++++++++++++++--
>  1 file changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
> index 1a9b4e7dae..2a49c6d05d 100644
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -443,6 +443,18 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
>      CHAR16 *pathend, *ptr;
>      EFI_STATUS ret;
>  
> +    /*
> +     * In some cases the image could not come from a specific device.
> +     * For instance this can happen if Xen was loaded using GRUB2 "linux"
> +     * command.
> +     */
> +    *leaf = buffer;

This feels wrong, if DeviceHandle is NULL, it will point at the
empty buffer that shouldn't really be used for anything anyway.

IMO a better option would be to add "&& dir_handle" to the condition
guarding use of file_name in efi_start() instead.

BTW, by my reading of get_parent_handle() theoretically it should be
possible to get _some_ name out of loaded_image->FilePath even without
dir_handle. But since it isn't going to be used, it's not worth it.

> +    if ( !loaded_image->DeviceHandle )
> +    {
> +        PrintStr(L"Xen image loaded without providing a device\r\n");
> +        return NULL;
> +    }
> +
>      do {
>          EFI_FILE_IO_INTERFACE *fio;
>  
> @@ -466,7 +478,15 @@ static EFI_FILE_HANDLE __init get_parent_handle(const EFI_LOADED_IMAGE *loaded_i
>  
>          if ( DevicePathType(dp) != MEDIA_DEVICE_PATH ||
>               DevicePathSubType(dp) != MEDIA_FILEPATH_DP )
> -            blexit(L"Unsupported device path component");
> +        {
> +            /*
> +             * The image could come from an unsupported device.
> +             * For instance this can happen if Xen was loaded using GRUB2
> +             * "chainloader" command and the file was not from ESP.
> +             */
> +            PrintStr(L"Unsupported device path component\r\n");
> +            return NULL;
> +        }
>  
>          if ( *buffer )
>          {
> @@ -772,6 +792,8 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>  
>      if ( !name )
>          PrintErrMesg(L"No filename", EFI_OUT_OF_RESOURCES);
> +    if ( !dir_handle )
> +        return false;

There are a lot of places where read_file() is used without checking its
return value. Which made sense since before this change the only cases
where read_file() would return false was for the config file, in all
other cases it handled errors via blexit().
Most of those read_file() calls seems to be fine (as in, will not
explode), but may still be confusing. For example when you embed a
config with "xsm=policy" (but the actual policy is not embedded) now the
failure to load it will result just a warning ("Xen image loaded without
providing a device") not even related to the file name and it will
continue booting with unintended configuration.

For me it looks like this change is wrong: if the config specified a
file to load (and that blob was not embedded in the UKI), and yet it
couldn't be loaded, it should fail early.
Is there any (new) case where where read_file() failure (when it
actually gets to calling it) should really be non-fatal now? 

In relation to the next patch - such UKI should simply not specify
ramdisk in the embedded config, to allow loading it via "initrd"
command. This would avoid calling read_file().

>      ret = dir_handle->Open(dir_handle, &FileHandle, name,
>                             EFI_FILE_MODE_READ, 0);
>      if ( file == &cfg && ret == EFI_NOT_FOUND )
> @@ -1515,7 +1537,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle,
>          efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
>          cfg.addr = 0;
>  
> -        dir_handle->Close(dir_handle);
> +        if ( dir_handle )
> +            dir_handle->Close(dir_handle);
>  
>          if ( gop && !base_video )
>          {
> -- 
> 2.43.0
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2025-06-24 12:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-24  8:31 [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2 Frediano Ziglio
2025-06-24  8:31 ` [PATCH 1/2] xen/efi: Handle cases where file didn't come from ESP Frediano Ziglio
2025-06-24 12:38   ` Marek Marczykowski-Górecki [this message]
2025-06-24 14:05     ` Frediano Ziglio
2025-06-24 14:35       ` Marek Marczykowski-Górecki
2025-06-24 15:12         ` Frediano Ziglio
2025-06-24 15:28           ` Marek Marczykowski-Górecki
2025-06-24 16:18         ` Jan Beulich
2025-06-24  8:31 ` [PATCH 2/2] xen/efi: Support loading initrd using GRUB2 LoadFile2 protocol Frediano Ziglio
2025-06-24 12:46   ` Marek Marczykowski-Górecki
2025-06-24  8:38 ` [PATCH 0/2] xen/efi: Make boot more flexible, especially with GRUB2 Frediano Ziglio
2025-06-25 20:26   ` Marek Marczykowski-Górecki
2025-06-26  8:12     ` Frediano Ziglio
2025-06-26 15:02       ` Marek Marczykowski-Górecki
2025-06-27 12:29         ` Frediano Ziglio
2025-06-27 14:20           ` Marek Marczykowski-Górecki
2025-06-27 15:58             ` Frediano Ziglio
2025-06-27 16:19               ` Marek Marczykowski-Górecki
2025-07-01 14:31                 ` Frediano Ziglio
2025-07-01 15:18                   ` Marek Marczykowski-Górecki
2025-07-09  9:33                     ` Frediano Ziglio

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=aFqcQe5quyjhu24P@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=frediano.ziglio@cloud.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.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.