public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context
Date: Tue, 5 Mar 2019 16:19:09 +0000	[thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F54FAE7@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <CAKv+Gu_XNobzi+COBGwSVf5hyctbK7Sgf99t8hUMcUEg5hBfrA@mail.gmail.com>

For current X86 world, we do use both SmmReadyToLock and EndOfDxe, for almost all X86 platform.

So, let me clarify:
If we try to align with PI spec, we can add EndOfDxe/ReadyToBoot/ExitBootService.
If we try to align with security, we can add EndOfDxe/SmmReadyToLock.

It depends upon the what goal we want to achieve. That is why I ask if we have specific use case.

Anyway, I think we can add when it is really needed later.
So I am OK with current patch.

Thank you
Yao Jiewen

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Tuesday, March 5, 2019 8:07 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal
> architected PI events into MM context
> 
> On Tue, 5 Mar 2019 at 17:04, Yao, Jiewen <jiewen.yao@intel.com> wrote:
> >
> > OK. To keep the compatibility of existing MM driver. That makes sense.
> >
> > If it is for security, I think EndOfDxe is the only point.
> > ReadyToBoot and ExitBootService cannot be used for security purpose.
> >
> 
> OK, good to know. I will keep them for the time being - MM drivers may
> be able to release resources or do other useful things when the
> non-secure side enters runtime mode.
> 
> > Then do we need SmmReadyToLock ? :-)
> >
> 
> Good point. It looked fairly x86 specific to me. Do you think it is
> likely to be used in OEM code running in MM mode?
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> Of
> > > Ard Biesheuvel
> > > Sent: Tuesday, March 5, 2019 7:58 AM
> > > To: Yao, Jiewen <jiewen.yao@intel.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe:
> signal
> > > architected PI events into MM context
> > >
> > > On Tue, 5 Mar 2019 at 16:56, Yao, Jiewen <jiewen.yao@intel.com>
> wrote:
> > > >
> > > > Hi
> > > > In original SMM infrastructure, there are lots of interaction that SMM
> has
> > > to know the DXE status.
> > > >
> > > > In StandaloneMm, I don't expect we have many interaction. Is there
> any
> > > specific example?
> > > >
> > > > I am totally OK to add those. And I just want to know more usage.
> > > >
> > > > Reviewed-by: Jiewen.yao@intel.com
> > > >
> > >
> > > Jiewen,
> > >
> > > Thanks for the review.
> > >
> > > It is not 100% clear at the moment, but since existing third party
> > > software designed to run in MM context may make assumptions about
> > > security of the platform (e.g., before vs after end of dxe) based on
> > > these events, we should at least signal the common ones added in this
> > > patch.
> > >
> > >
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > > > > Sent: Tuesday, March 5, 2019 5:33 AM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Achin Gupta
> > > > > <achin.gupta@arm.com>; Supreeth Venkatesh
> > > > > <supreeth.venkatesh@arm.com>; Yao, Jiewen
> <jiewen.yao@intel.com>;
> > > > > Leif Lindholm <leif.lindholm@linaro.org>; Jagadeesh Ujja
> > > > > <jagadeesh.ujja@arm.com>
> > > > > Subject: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal
> > > architected
> > > > > PI events into MM context
> > > > >
> > > > > PI defines a few architected events that have significance in the MM
> > > > > context as well as in the non-secure DXE context. So register notify
> > > > > handlers for these events, and relay them into the standalone MM
> world.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > > ---
> > > > >  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf |
> 5
> > > +++
> > > > >  ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c   |
> 47
> > > > > +++++++++++++++++++-
> > > > >  2 files changed, 50 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git
> > > a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> > > > > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> > > > > index 88beafa39c05..8bf269270f9d 100644
> > > > > --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> > > > > +++
> b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> > > > > @@ -48,6 +48,11 @@ [LibraryClasses]
> > > > >  [Protocols]
> > > > >    gEfiMmCommunicationProtocolGuid              ##
> PRODUCES
> > > > >
> > > > > +[Guids]
> > > > > +  gEfiEndOfDxeEventGroupGuid
> > > > > +  gEfiEventExitBootServicesGuid
> > > > > +  gEfiEventReadyToBootGuid
> > > > > +
> > > > >  [Pcd.common]
> > > > >    gArmTokenSpaceGuid.PcdMmBufferBase
> > > > >    gArmTokenSpaceGuid.PcdMmBufferSize
> > > > > diff --git
> > > a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > > > > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > > > > index feb9fa9f4ead..3203cf801a19 100644
> > > > > --- a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > > > > +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c
> > > > > @@ -265,6 +265,43 @@ GetMmCompatibility ()
> > > > >    return Status;
> > > > >  }
> > > > >
> > > > > +STATIC EFI_GUID* CONST mGuidedEventGuid[] = {
> > > > > +  &gEfiEndOfDxeEventGroupGuid,
> > > > > +  &gEfiEventExitBootServicesGuid,
> > > > > +  &gEfiEventReadyToBootGuid,
> > > > > +};
> > > > > +
> > > > > +STATIC EFI_EVENT mGuidedEvent[ARRAY_SIZE
> (mGuidedEventGuid)];
> > > > > +
> > > > > +/**
> > > > > +  Event notification that is fired when GUIDed Event Group is
> signaled.
> > > > > +
> > > > > +  @param  Event                 The Event that is being
> > > processed,
> > > > > not used.
> > > > > +  @param  Context               Event Context, not used.
> > > > > +
> > > > > +**/
> > > > > +STATIC
> > > > > +VOID
> > > > > +EFIAPI
> > > > > +MmGuidedEventNotify (
> > > > > +  IN EFI_EVENT  Event,
> > > > > +  IN VOID       *Context
> > > > > +  )
> > > > > +{
> > > > > +  EFI_MM_COMMUNICATE_HEADER   Header;
> > > > > +  UINTN                       Size;
> > > > > +
> > > > > +  //
> > > > > +  // Use Guid to initialize EFI_SMM_COMMUNICATE_HEADER
> structure
> > > > > +  //
> > > > > +  CopyGuid (&Header.HeaderGuid, Context);
> > > > > +  Header.MessageLength = 1;
> > > > > +  Header.Data[0] = 0;
> > > > > +
> > > > > +  Size = sizeof (Header);
> > > > > +  MmCommunicationCommunicate (&mMmCommunication,
> &Header,
> > > > > &Size);
> > > > > +}
> > > > > +
> > > > >  /**
> > > > >    The Entry Point for MM Communication
> > > > >
> > > > > @@ -287,6 +324,7 @@ MmCommunicationInitialize (
> > > > >    )
> > > > >  {
> > > > >    EFI_STATUS                 Status;
> > > > > +  UINTN                      Index;
> > > > >
> > > > >    // Check if we can make the MM call
> > > > >    Status = GetMmCompatibility ();
> > > > > @@ -351,8 +389,13 @@ MmCommunicationInitialize (
> > > > >                    NULL,
> > > > >                    &mSetVirtualAddressMapEvent
> > > > >                    );
> > > > > -  if (Status == EFI_SUCCESS) {
> > > > > -    return Status;
> > > > > +  ASSERT_EFI_ERROR (Status);
> > > > > +
> > > > > +  for (Index = 0; Index < ARRAY_SIZE (mGuidedEventGuid); Index++)
> {
> > > > > +    Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL,
> > > TPL_CALLBACK,
> > > > > +                    MmGuidedEventNotify,
> > > mGuidedEventGuid[Index],
> > > > > +                    mGuidedEventGuid[Index],
> > > > > &mGuidedEvent[Index]);
> > > > > +    ASSERT_EFI_ERROR (Status);
> > > > >    }
> > > > >
> > > > >    gBS->UninstallProtocolInterface (
> > > > > --
> > > > > 2.20.1
> > > >
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2019-03-05 16:19 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 13:32 [PATCH 00/10] StandaloneMmPkg, ArmPkg: cleanups and improvements Ard Biesheuvel
2019-03-05 13:32 ` [PATCH 01/10] StandaloneMmPkg: drop redundant definition of gEfiMmConfigurationProtocolGuid Ard Biesheuvel
2019-03-05 13:53   ` Yao, Jiewen
2019-03-05 13:32 ` [PATCH 02/10] StandaloneMmPkg: drop unused PCD PcdStandaloneMmEnable Ard Biesheuvel
2019-03-05 13:55   ` Yao, Jiewen
2019-03-06 15:16   ` Achin Gupta
2019-03-06 15:17     ` Ard Biesheuvel
2019-03-06 15:37       ` Achin Gupta
2019-03-07 10:09         ` Ard Biesheuvel
2019-03-07 11:14           ` Achin Gupta
2019-03-05 13:32 ` [PATCH 03/10] StandaloneMmPkg: switch to NULL DebugLib resolution Ard Biesheuvel
2019-03-05 14:22   ` Yao, Jiewen
2019-03-06 15:38   ` Achin Gupta
2019-03-05 13:32 ` [PATCH 04/10] StandaloneMmPkg: remove redundant StandaloneMmDriverEntryPoint driver Ard Biesheuvel
2019-03-05 14:22   ` Yao, Jiewen
2019-03-05 13:32 ` [PATCH 05/10] StandaloneMmPkg/StandaloneMmCoreEntryPoint: drop explicit SerialPortLib call Ard Biesheuvel
2019-03-05 13:52   ` Yao, Jiewen
2019-03-06 16:35   ` Achin Gupta
2019-03-06 16:41     ` Ard Biesheuvel
2019-03-06 16:55       ` Achin Gupta
2019-03-05 13:32 ` [PATCH 06/10] StandaloneMmPkg/Core: permit encapsulated firmware volumes Ard Biesheuvel
2019-03-05 15:50   ` Yao, Jiewen
2019-03-06 16:56   ` Achin Gupta
2019-03-05 13:32 ` [PATCH 07/10] StandaloneMmPkg/Core: dispatch all drivers at init time Ard Biesheuvel
2019-03-05 15:51   ` Yao, Jiewen
2019-03-06 16:56   ` Achin Gupta
2019-03-05 13:32 ` [PATCH 08/10] StandaloneMmPkg/Core: drop support for dispatching FVs into MM Ard Biesheuvel
2019-03-05 15:51   ` Yao, Jiewen
2019-03-06 16:58   ` Achin Gupta
2019-03-05 13:32 ` [PATCH 09/10] StandaloneMmPkg/Core: remove legacy boot support Ard Biesheuvel
2019-03-05 13:52   ` Yao, Jiewen
2019-03-06 16:59   ` Achin Gupta
2019-03-05 13:32 ` [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context Ard Biesheuvel
2019-03-05 15:55   ` Yao, Jiewen
2019-03-05 15:58     ` Ard Biesheuvel
2019-03-05 16:04       ` Yao, Jiewen
2019-03-05 16:07         ` Ard Biesheuvel
2019-03-05 16:19           ` Yao, Jiewen [this message]
2019-03-05 16:53             ` Felix Polyudov
2019-03-05 17:29               ` Ard Biesheuvel
2019-03-06 16:58   ` Achin Gupta
2019-03-11 11:54 ` [PATCH 00/10] StandaloneMmPkg, ArmPkg: cleanups and improvements Ard Biesheuvel
2019-03-11 11:59   ` 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-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=74D8A39837DF1E4DA445A8C0B3885C503F54FAE7@shsmsx102.ccr.corp.intel.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