public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Taylor Beebe <t@taylorbeebe.com>,
	Oliver Smith-Denny <osd@smith-denny.com>,
	"Bi, Dandan" <dandan.bi@intel.com>,
	"Gao, Liming" <gaoliming@byosoft.com.cn>,
	"Kinney, Michael D" <michael.d.kinney@intel.com>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Michael Kubacki <mikuback@linux.microsoft.com>
Subject: Re: [RFC PATCH 07/11] MdeModulePkg/DxeCore: Execute loaded images in place if possible
Date: Tue, 30 May 2023 06:32:11 +0000	[thread overview]
Message-ID: <MN6PR11MB8244CFE52B8D3E72EA6EC1148C4B9@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230529101705.2476949-8-ardb@kernel.org>

I didn't review the existing logic carefully. Several comments:
1. Assignments of several fields are skipped when executing in place. Do they matter?
    a). Image->NumberOfPages
    b). Image->ImageBasePage

2. PeCoffLoaderRelocateImage() is called even for XIP case. But I don't think it's expected that relocation really happens. Even if the fixed data is the same as the original data stored in MMIO device, MMIO writing might cause unexpected behavior.

3.  CoreFreePages() is called when image is not loaded successfully. Is it expected for XIP case?

Thanks,
Ray

> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Monday, May 29, 2023 6:17 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel <ardb@kernel.org>; Ni, Ray <ray.ni@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Taylor Beebe
> <t@taylorbeebe.com>; Oliver Smith-Denny <osd@smith-denny.com>; Bi, Dandan
> <dandan.bi@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Kinney,
> Michael D <michael.d.kinney@intel.com>; Leif Lindholm
> <quic_llindhol@quicinc.com>; Michael Kubacki <mikuback@linux.microsoft.com>
> Subject: [RFC PATCH 07/11] MdeModulePkg/DxeCore: Execute loaded images in
> place if possible
> 
> In the image loader, check whether an image has already been relocated
> to the address from which it is being loaded. This is not something that
> can happen by accident, and so we can assume that this means that the
> image was intended to be executed in place.
> 
> This removes a redundant copy of the image contents, and also permits
> the image to be mapped with restricted permissions even before the CPU
> arch protocol has been dispatched.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  MdeModulePkg/Core/Dxe/Image/Image.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c
> b/MdeModulePkg/Core/Dxe/Image/Image.c
> index 3dfab4829b3ca17f..621637e869daf62d 100644
> --- a/MdeModulePkg/Core/Dxe/Image/Image.c
> +++ b/MdeModulePkg/Core/Dxe/Image/Image.c
> @@ -573,7 +573,7 @@ STATIC
>  EFI_STATUS
> 
>  CoreLoadPeImage (
> 
>    IN BOOLEAN                    BootPolicy,
> 
> -  IN VOID                       *Pe32Handle,
> 
> +  IN IMAGE_FILE_HANDLE          *Pe32Handle,
> 
>    IN LOADED_IMAGE_PRIVATE_DATA  *Image,
> 
>    IN  UINT32                    Attribute
> 
>    )
> 
> @@ -630,10 +630,16 @@ CoreLoadPeImage (
>        return EFI_UNSUPPORTED;
> 
>    }
> 
> 
> 
> +  //
> 
> +  // Check whether the loaded image can be executed in place
> 
> +  //
> 
> +  if (Image->ImageContext.ImageAddress ==
> (PHYSICAL_ADDRESS)(UINTN)Pe32Handle->Source) {
> 
> +    goto ExecuteInPlace;
> 
> +  }
> 
> +
> 
>    //
> 
>    // Allocate Destination Buffer as caller did not pass it in
> 
>    //
> 
> -
> 
>    if (Image->ImageContext.SectionAlignment > EFI_PAGE_SIZE) {
> 
>      Size = (UINTN)Image->ImageContext.ImageSize + Image-
> >ImageContext.SectionAlignment;
> 
>    } else {
> 
> @@ -704,6 +710,7 @@ CoreLoadPeImage (
>    //
> 
>    // Load the image from the file into the allocated memory
> 
>    //
> 
> +ExecuteInPlace:
> 
>    Status = PeCoffLoaderLoadImage (&Image->ImageContext);
> 
>    if (EFI_ERROR (Status)) {
> 
>      goto Done;
> 
> --
> 2.39.2


  reply	other threads:[~2023-05-30  6:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-29 10:16 [RFC PATCH 00/11] Permit DXE drivers to execute in place Ard Biesheuvel
2023-05-29 10:16 ` [RFC PATCH 01/11] MdeModulePkg/DxeCore: Remove unused 'EntryPoint' argument to LoadImage Ard Biesheuvel
2023-05-30  5:54   ` Ni, Ray
2023-05-30  7:36     ` Ard Biesheuvel
2023-05-29 10:16 ` [RFC PATCH 02/11] MdeModulePkg/DxeCore: Remove unused DstBuffer arg from LoadImage Ard Biesheuvel
2023-05-30  5:58   ` Ni, Ray
2023-05-29 10:16 ` [RFC PATCH 03/11] MdeModulePkg/DxeCore: Remove FreePage argument from CoreUnloadImage Ard Biesheuvel
2023-05-30  5:59   ` Ni, Ray
2023-05-29 10:16 ` [RFC PATCH 04/11] MdeModulePkg/DxeCore: Avoid caching memory mapped FFS files Ard Biesheuvel
2023-05-30  6:03   ` Ni, Ray
2023-05-30  7:47     ` Ard Biesheuvel
2023-05-29 10:16 ` [RFC PATCH 05/11] MdeModulePkg/DxeCore: Use memory mapped FV protocol to avoid image copy Ard Biesheuvel
2023-05-30  6:21   ` Ni, Ray
2023-05-30  7:51     ` [edk2-devel] " Ard Biesheuvel
2023-05-30  8:40       ` Ni, Ray
2023-05-30  8:51         ` Ard Biesheuvel
2023-05-29 10:17 ` [RFC PATCH 06/11] MdeModulePkg/DxeCore: Expose memory mapped FV protocol when possible Ard Biesheuvel
2023-05-30  6:22   ` Ni, Ray
2023-05-29 10:17 ` [RFC PATCH 07/11] MdeModulePkg/DxeCore: Execute loaded images in place if possible Ard Biesheuvel
2023-05-30  6:32   ` Ni, Ray [this message]
2023-05-30  7:54     ` Ard Biesheuvel
2023-05-29 10:17 ` [RFC PATCH 08/11] MdeModulePkg/DxeIpl: Relocate and remap XIP capable DXE drivers Ard Biesheuvel
2023-05-30  6:45   ` [edk2-devel] " Ni, Ray
2023-05-30  7:58     ` Ard Biesheuvel
2023-05-30  8:02       ` Ni, Ray
2023-05-30  8:29         ` Ard Biesheuvel
2023-05-30  9:06       ` Marvin Häuser
2023-05-30  9:18         ` Marvin Häuser
2023-05-30  9:38         ` Ard Biesheuvel
2023-05-30  9:41           ` Marvin Häuser
2023-05-30  9:47             ` Ard Biesheuvel
2023-05-30  9:48               ` Ard Biesheuvel
2023-05-30  9:52                 ` Marvin Häuser
2023-05-30 10:02                   ` Ard Biesheuvel
2023-05-30 10:25                     ` Marvin Häuser
2023-05-31  7:13                       ` Ni, Ray
2023-05-31  8:05                         ` Marvin Häuser
2023-05-29 10:17 ` [RFC PATCH 09/11] MdeModulePkg/DxeCore: Add PCD NX policy bit for default NX state Ard Biesheuvel
2023-05-30  6:54   ` Ni, Ray
2023-05-30  8:33     ` Ard Biesheuvel
2023-05-29 10:17 ` [RFC PATCH 10/11] ArmVirtPkg/ArmVirtQemu: Allow CPU arch protocol DXE to execute in place Ard Biesheuvel
2023-05-29 10:17 ` [RFC PATCH 11/11] ArmVirtPkg/ArmVirtQemu: Map all DRAM non-execute by default Ard Biesheuvel
2023-06-01 14:53 ` [edk2-devel] [RFC PATCH 00/11] Permit DXE drivers to execute in place Oliver Smith-Denny
2023-06-01 18:11   ` Ard Biesheuvel
2023-06-01 18:30     ` Oliver Smith-Denny

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-list 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=MN6PR11MB8244CFE52B8D3E72EA6EC1148C4B9@MN6PR11MB8244.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /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