From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.115; helo=mga14.intel.com; envelope-from=jiewen.yao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 5BA58211CC3A7 for ; Tue, 5 Mar 2019 08:19:19 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 08:19:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,444,1544515200"; d="scan'208";a="139335910" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 05 Mar 2019 08:19:12 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Mar 2019 08:19:11 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.163]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.80]) with mapi id 14.03.0415.000; Wed, 6 Mar 2019 00:19:10 +0800 From: "Yao, Jiewen" To: 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//e5MAgACIj5A= Date: Tue, 5 Mar 2019 16:19:09 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F54FAE7@shsmsx102.ccr.corp.intel.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> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGViMTQ4Y2ItYWUxZS00YWI5LWE1ODQtMzM1MDQ2MDQ4MmJkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZHdrNUIzWVM3Y2Q4VkRFbmp1cEx3ekh0dGZYMEljTk45OXlBZ3pkOG1wb0pNMGRDQXZHXC90MEZIbW9pV2lcL3RxIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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:19:19 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For current X86 world, we do use both SmmReadyToLock and EndOfDxe, for almo= st all X86 platform. So, let me clarify: If we try to align with PI spec, we can add EndOfDxe/ReadyToBoot/ExitBootSe= rvice. 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 h= ave 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 >=20 > 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. > > >=20 > 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. >=20 > > Then do we need SmmReadyToLock ? :-) > > >=20 > 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? >=20 >=20 >=20 >=20 > > > -----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 = 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 ; 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 not= ify > > > > > 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