From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=63.147.10.42; helo=atlmailgw2.ami.com; envelope-from=felixp@ami.com; receiver=edk2-devel@lists.01.org Received: from atlmailgw2.ami.com (atlmailgw2.ami.com [63.147.10.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1FBD5211CFFDD for ; Tue, 5 Mar 2019 08:53:19 -0800 (PST) X-AuditID: ac10606f-64fff700000073c3-6d-5c7ea97e2c9f Received: from atlms2.us.megatrends.com (atlms2.us.megatrends.com [172.16.96.152]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by atlmailgw2.ami.com (Symantec Messaging Gateway) with SMTP id 21.05.29635.E79AE7C5; Tue, 5 Mar 2019 11:53:18 -0500 (EST) Received: from ATLMS1.us.megatrends.com ([fe80::8c55:daf0:ef05:5605]) by atlms2.us.megatrends.com ([fe80::29dc:a91e:ea0c:cdeb%12]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 11:53:18 -0500 From: Felix Polyudov To: "'Yao, Jiewen'" , Ard Biesheuvel CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context Thread-Index: AQHU01gHsWIGO5SrkEKCv9e2NMWx8qX9EHRw//+bSYCAAIbkoP//e5MAgACIj5CAAAh+0A== Date: Tue, 5 Mar 2019 16:53:18 +0000 Message-ID: <9333E191E0D52B4999CE63A99BA663A00302C6A7AB@atlms1.us.megatrends.com> References: <20190305133248.4828-1-ard.biesheuvel@linaro.org> <20190305133248.4828-11-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C503F54D1FD@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F54F0BB@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503F54FAE7@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503F54FAE7@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.99.93] content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsWyRiBhhm7dyroYg90XTCz+f9jNaLHn0FFm i3UfPRyYPRbvecnkcefaHjaP7tn/WAKYoxoYbRLz8vJLEktSFVJSi5NtlQKKMssSkyuVFDJT bJUMlRQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66rZJnsL+uhYWppa6h kl1IRqpCZl5aflFuYklmfp5Ccn5eCVB1agpQVCGhizPj3YIvjAWrvCvmbdvN1MA417KLkZND QsBEYta2l+xdjFwcQgK7mCTWzXzMCuEcYpS43HiIDaSKTUBV4vjqZhYQW0QgQuLGk5XMIDaz gLnE29evGUFsYYFsiVXfp7JD1ORIfDjwnAnCDpN4vX8jWC+LgIrEnpcvwOK8AoESHT3zwHqF BO4xS8xp0e9i5ODgFAiR2Pi/EiTMKCAm8f3UGiaIVeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9Y IWwFiS3vO9kh6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKK USixJCc3MTMnvdxILzE3Uy85P3cTIyRF5O9g/PjR/BCjAAejEg9v/bK6GCHWxLLiylxgSHIw K4nw/msHCvGmJFZWpRblxxeV5qQWH2J0AobKRGYpblB0AeM/3tjAQEoUxjE0MTMxNzI3tDQx NzZWEufNV/sUJSSQDkxH2ampBalFMEOYODilGhgld06+uj+x7/CvTW59piW1jk0GKouyE0/H rfl7Ysrp1fqTtZ4syjOOClBv8LgSatiT2HYlVfOxKRv/Rqv2eF7vO2k7jZ4+ebJATUPwzlmO 1eo3WzJUQ+UuTizx+XdEpyZhVtaxk2p/4zdtWP/0V1Di1Lbn6+52fYorCK7g2BvZpFKXWrX4 b4cSS3FGoqEWc1FxIgBfcSPWNAMAAA== Subject: Re: [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architected PI events into MM context X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:53:20 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" There is an architectural difference between EndOfDxe and SmmReadyToLock eve= nts. It's important to have both of them. Here is what PI specification says: =3D=3D Transition from the environment where all of the components are under the au= thority of the platform manufacturer to the environment where third party mo= dules are executed is a two-step process: 1.End of DXE Event is signaled. This event presents the last opportunity to= use resources or interfaces that are going to be locked or disabled in anti= cipation of the invocation of 3rd party extensible modules. 2.DXE SMM Ready to Lock Protocol is installed. PI modules that need to lock= or protect their resources in anticipation of the invocation of 3rd party e= xtensible modules should register for notification on installation of this p= rotocol and effect the appropriate protections in their notification handler= s =3D=3D -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yao,= Jiewen Sent: Tuesday, March 05, 2019 11:19 AM To: Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: Re: [edk2] [PATCH 10/10] ArmPkg/MmCommunicationDxe: signal architec= ted PI events into MM context For current X86 world, we do use both SmmReadyToLock and EndOfDxe, for almos= t all X86 platform. So, let me clarify: If we try to align with PI spec, we can add EndOfDxe/ReadyToBoot/ExitBootSer= vice. 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 ha= ve 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 > 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 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 > > > 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 > wrote: > > > > > > > > Hi > > > > In original SMM infrastructure, there are lots of interaction that S= MM > 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 ; Achin Gupta > > > > > ; Supreeth Venkatesh > > > > > ; Yao, Jiewen > ; > > > > > Leif Lindholm ; Jagadeesh Ujja > > > > > > > > > > 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 noti= fy > > > > > handlers for these events, and relay them into the standalone MM > world. > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > Signed-off-by: Ard Biesheuvel > > > > > --- > > > > > 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[] =3D { > > > > > + &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 =3D 1; > > > > > + Header.Data[0] =3D 0; > > > > > + > > > > > + Size =3D 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 =3D GetMmCompatibility (); > > > > > @@ -351,8 +389,13 @@ MmCommunicationInitialize ( > > > > > NULL, > > > > > &mSetVirtualAddressMapEvent > > > > > ); > > > > > - if (Status =3D=3D EFI_SUCCESS) { > > > > > - return Status; > > > > > + ASSERT_EFI_ERROR (Status); > > > > > + > > > > > + for (Index =3D 0; Index < ARRAY_SIZE (mGuidedEventGuid); Index+= +) > { > > > > > + Status =3D 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Please consider the environment before printing this email. The information contained in this message may be confidential and proprietar= y to American Megatrends, Inc. This communication is intended to be read on= ly by the individual or entity to whom it is addressed or by their designee.= If the reader of this message is not the intended recipient, you are on not= ice that any distribution of this message, in any form, is strictly prohibit= ed. Please promptly notify the sender by reply e-mail or by telephone at 77= 0-246-8600, and then delete or destroy all copies of the transmission.