public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: Dionna Glaze <dionnaglaze@google.com>, Ray Ni <ray.ni@intel.com>
Cc: devel@edk2.groups.io, Gerd Hoffmann <kraxel@redhat.com>,
	 James Bottomley <jejb@linux.ibm.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>,
	"Min M. Xu" <min.m.xu@intel.com>,  Andrew Fish <afish@apple.com>,
	"Michael D. Kinney" <michael.d.kinney@intel.com>
Subject: Re: [PATCH v5 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices
Date: Mon, 3 Oct 2022 13:33:54 +0200	[thread overview]
Message-ID: <CAMj1kXFkqg=3LyEr_9UNm_Vo7SaaKc8zWBwmzDs7nZYBGEwxMQ@mail.gmail.com> (raw)
In-Reply-To: <20220930230627.3371754-4-dionnaglaze@google.com>

(cc Ray)

On Sat, 1 Oct 2022 at 01:06, Dionna Glaze <dionnaglaze@google.com> wrote:
>
> The protocol's intent is to allow drivers to install callbacks that can
> modify the memory map at ExitBootServices time, so that any changes will
> lead to the EFI_INVALID_PARAMETER error. This error is specified to require
> the EBS caller to call GetMemoryMap again if it already had.
>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: James Bottomley <jejb@linux.ibm.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: "Min M. Xu" <min.m.xu@intel.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com>
>
> Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.inf       |  1 +
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 62 ++++++++++++++++++++
>  2 files changed, 63 insertions(+)
>
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf b/MdeModulePkg/Core/Dxe/DxeMain.inf
> index e4bca89577..bdd9cf8222 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> @@ -153,6 +153,7 @@
>    gEfiHiiPackageListProtocolGuid                ## SOMETIMES_PRODUCES
>    gEfiSmmBase2ProtocolGuid                      ## SOMETIMES_CONSUMES
>    gEdkiiPeCoffImageEmulatorProtocolGuid         ## SOMETIMES_CONSUMES
> +  gEdkiiExitBootServicesCallbackProtocolGuid    ## CONSUMES
>
>    # Arch Protocols
>    gEfiBdsArchProtocolGuid                       ## CONSUMES
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> index 5733f0c8ec..8cf7d6bcbf 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -6,6 +6,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
>
> +#include <Protocol/ExitBootServicesCallback.h>

This include belongs in DxeMain.h



>  #include "DxeMain.h"
>
>  //
> @@ -744,6 +745,54 @@ CalculateEfiHdrCrc (
>    Hdr->CRC32 = Crc;
>  }
>
> +/**
> +  Invokes TerminateMemoryMapPrehook from every instance of the
> +  EdkiiExitBootServicesProtocol.
> +**/
> +STATIC
> +EFI_STATUS
> +InvokeTerminateMemoryMapPrehooks (
> +  VOID
> +  )

We should decide whether or not we want to support a multitude of
these callback protocols. Some protocols in EFI are simply considered
singleton protocols, and I think we might want to stick with that
approach for the time being, as it makes the code much simpler,
especially because most users of this code are not confidential
compute.

> +{
> +  UINTN       NoHandles;
> +  UINTN       Index;
> +  EFI_HANDLE  *HandleBuffer;
> +  EFI_STATUS  Status;
> +  EDKII_EXIT_BOOT_SERVICES_CALLBACK_PROTOCOL *Callback;
> +
> +  Status = gBS->LocateHandleBuffer (
> +                  ByProtocol,
> +                  &gEdkiiExitBootServicesCallbackProtocolGuid,
> +                  NULL,
> +                  &NoHandles,
> +                  &HandleBuffer
> +                  );
> +  if (EFI_ERROR (Status) && NoHandles == 0) {
> +    return Status;
> +  }
> +
> +  for (Index = 0; Index < NoHandles; Index++) {
> +    Status = gBS->HandleProtocol (
> +                    HandleBuffer[Index],
> +                    &gEdkiiExitBootServicesCallbackProtocolGuid,
> +                    (VOID **)&Callback
> +                    );
> +    if (EFI_ERROR (Status)) {
> +      continue;
> +    }
> +
> +    Status = Callback->TerminateMemoryMapPrehook(Callback);
> +    if (EFI_ERROR (Status) || Status == EFI_WARN_STALE_DATA) {

EFI_WARN_STALE_DATA is not an error, so this routine might return a
non-error, which we fail to check for below.

Also, if multiple protocols exist, shouldn't we invoke all of them,
and collate the return codes in some way?

(Another reason to stick with a singleton protocol)

> +      goto done;
> +    }
> +  }
> +
> +done:
> +  FreePool(HandleBuffer);
> +  return Status;
> +}
> +
>  /**
>    Terminates all boot services.
>
> @@ -768,6 +817,19 @@ CoreExitBootServices (
>    //
>    gTimer->SetTimerPeriod (gTimer, 0);
>
> +  //
> +  // Invoke all protocols installed for ExitBootServices prior to
> +  // CoreTerminateMemoryMap.
> +  //
> +  Status = InvokeTerminateMemoryMapPrehooks();
> +  if (EFI_ERROR (Status)) {

This condition does not hold for EFI_WARN_STALE_DATA, nor is
EFI_WARN_STALE_DATA documented as a valid return value for
ExitBootServices().


> +    //
> +    // Notify other drivers that ExitBootServices failed
> +    //
> +    CoreNotifySignalList (&gEventExitBootServicesFailedGuid);
> +    return Status;
> +  }
> +
>    //
>    // Terminate memory services if the MapKey matches
>    //
> --
> 2.38.0.rc1.362.ged0d419d3c-goog
>

  reply	other threads:[~2022-10-03 11:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-30 23:06 [PATCH v5 0/7] Add safe unaccepted memory behavior Dionna Glaze
2022-09-30 23:06 ` [PATCH v5 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe Dionna Glaze
2022-10-03 14:52   ` Lendacky, Thomas
2022-09-30 23:06 ` [PATCH v5 2/7] MdePkg: Introduce ExitBootServicesCallbackProtocol Dionna Glaze
2022-10-01  0:15   ` [edk2-devel] " Ni, Ray
2022-10-03  1:16     ` Dionna Glaze
2022-10-03 11:23       ` Ard Biesheuvel
2022-10-03 17:25         ` Dionna Glaze
2022-10-05 16:20         ` Felix Polyudov
2022-10-05 16:54           ` Dionna Glaze
2022-09-30 23:06 ` [PATCH v5 3/7] MdeModulePkg: Invoke all ExitBootServicesCallback instances at ExitBootServices Dionna Glaze
2022-10-03 11:33   ` Ard Biesheuvel [this message]
2022-09-30 23:06 ` [PATCH v5 4/7] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2022-09-30 23:06 ` [PATCH v5 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol Dionna Glaze
2022-09-30 23:06 ` [PATCH v5 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2022-09-30 23:06 ` [PATCH v5 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze

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='CAMj1kXFkqg=3LyEr_9UNm_Vo7SaaKc8zWBwmzDs7nZYBGEwxMQ@mail.gmail.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