From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=104.47.2.57; helo=eur01-db5-obe.outbound.protection.outlook.com; envelope-from=supreeth.venkatesh@arm.com; receiver=edk2-devel@lists.01.org Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0057.outbound.protection.outlook.com [104.47.2.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9DA43203BEA36 for ; Fri, 4 May 2018 16:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z7PeMrQjQwKI9+RibvhZ7LSuV+xij03iLXfca/1aDOc=; b=WKibsa3mUKf2/1K2U51UkTCJIqvcYxnUoHAwXL6QHXjCUWtuq5Wd02GzvJpZSh/RQ+W7Mr+3mo7fcGBLVO1H9rFjUPgqqYD3nMyuSt6uVyTk9IJzw3HRKOul2xq6qysSu2VDYhXUxn97/BqMhuGZUAscvKUhThGJHgYxkvlQ0eo= Received: from AM4PR0802MB2306.eurprd08.prod.outlook.com (10.172.218.15) by AM4PR0802MB2196.eurprd08.prod.outlook.com (10.172.217.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.735.16; Fri, 4 May 2018 23:18:28 +0000 Received: from AM4PR0802MB2306.eurprd08.prod.outlook.com ([fe80::e117:6f62:6a9b:6be4]) by AM4PR0802MB2306.eurprd08.prod.outlook.com ([fe80::e117:6f62:6a9b:6be4%8]) with mapi id 15.20.0735.016; Fri, 4 May 2018 23:18:27 +0000 From: Supreeth Venkatesh To: Achin Gupta CC: "edk2-devel@lists.01.org" Thread-Topic: [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver. Thread-Index: AQHTzbWMiTqwsuwzGkG+BaWwsKZd1KP7n3CAgB/EoOA= Date: Fri, 4 May 2018 23:18:27 +0000 Message-ID: References: <20180406144223.10931-1-supreeth.venkatesh@arm.com> <20180406144223.10931-3-supreeth.venkatesh@arm.com> <20180411140020.GE663@e104320-lin> In-Reply-To: <20180411140020.GE663@e104320-lin> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Supreeth.Venkatesh@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2196; 7:wVr481G0CTPLUKbrMel1PkJt+GHbFpOSAZzMHNEAtNE1OM2rZUWjNPNAJEBYnFhgfvHxepD0DCmCPntZRbG2Kff76weiToHt2LcOx1U6Q6tWwoG8uTuuGjD9pn6Bk0Uv3qZRIlHj5UEay4PYnKIr12rvgJxlrZ69swOjLbYjV2EFzt4pFu0o5HjPnafGprVoDyWhLWV3wia0NxAmn1wXYnH5vEh1TMLN0gMG3fDK5e5xtmu5H6Ar7NTinaUAAN+3 x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2196; x-ms-traffictypediagnostic: AM4PR0802MB2196: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(162533806227266)(228905959029699)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR0802MB2196; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2196; x-forefront-prvs: 06628F7CA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(39380400002)(396003)(376002)(366004)(13464003)(199004)(189003)(40434004)(105586002)(446003)(8936002)(106356001)(4326008)(11346002)(476003)(486006)(966005)(72206003)(5660300001)(6116002)(478600001)(305945005)(7736002)(3846002)(25786009)(81156014)(81166006)(8676002)(66066001)(14454004)(97736004)(316002)(5250100002)(3280700002)(99286004)(6246003)(86362001)(3660700001)(53946003)(74316002)(6306002)(9686003)(55016002)(6436002)(229853002)(102836004)(6862004)(2906002)(6636002)(6506007)(68736007)(59450400001)(53546011)(15188155005)(16799955002)(53376002)(33656002)(26005)(2900100001)(76176011)(7696005)(53936002)(5890100001)(579004)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2196; H:AM4PR0802MB2306.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /g+I9pfFMPpaePC6q6cko+FpIm3kQ6I2n78zsacfyd+kdFeXOfQvTkUBFM9qmGFIX/YYZug7ALP6lR83RSlDJCcIJGQQlqbKnv6/+qZj+1e040eZQp17arJjNyLF1Crg7ACKnz0LgWJuVvaJkPiyStX3w8GY12oeb5Sm6f+4WAsMCf7SUdcLYTDV3P5xnrLV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 2417934c-6bb2-42dc-dcaf-08d5b21557c1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2417934c-6bb2-42dc-dcaf-08d5b21557c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2018 23:18:27.8235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2196 Subject: Re: [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 23:18:31 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My response inline. -----Original Message----- From: Achin Gupta Sent: Wednesday, April 11, 2018 9:00 AM To: Supreeth Venkatesh Cc: edk2-devel@lists.01.org; michael.d.kinney@intel.com; liming.gao@intel.c= om; jiewen.yao@intel.com; leif.lindholm@linaro.org; ard.biesheuvel@linaro.o= rg; nd Subject: Re: [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROT= OCOL DXE driver. Hi Supreeth, CIL. On Fri, Apr 06, 2018 at 03:42:07PM +0100, Supreeth Venkatesh wrote: > PI v1.5 Specification Volume 4 defines Management Mode Core Interface > and defines EFI_MM_COMMUNICATION_PROTOCOL. This protocol provides a > means of communicating between drivers outside of MM and MMI handlers > inside of MM. > > This patch implements the EFI_MM_COMMUNICATION_PROTOCOL DXE runtime > driver for AARCH64 platforms. It uses SMCs allocated from the standard > SMC range defined in DEN0060A_ARM_MM_Interface_Specification.pdf > to communicate with the standalone MM environment in the secure world. > > This patch also adds the MM Communication driver (.inf) file to define > entry point for this driver and other compile related information the > driver needs. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Achin Gupta > Signed-off-by: Supreeth Venkatesh > --- > .../Drivers/MmCommunicationDxe/MmCommunication.c | 339 +++++++++++++++= ++++++ > .../Drivers/MmCommunicationDxe/MmCommunication.inf | 50 +++ > 2 files changed, 389 insertions(+) > create mode 100644 > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c > create mode 100644 > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > > diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c > new file mode 100644 > index 0000000000..e801c1c601 > --- /dev/null > +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.c > @@ -0,0 +1,339 @@ > +/** @file > + > + Copyright (c) 2016-2017, ARM Limited. All rights reserved. > + > + This program and the accompanying materials are licensed and made > + available under the terms and conditions of the BSD License which > + accompanies this distribution. The full text of the license may be > + found at http://opensource.org/licenses/bsd-license.php > + > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > + BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRE= SS OR IMPLIED. > + > +**/ > + > +#include > +#include > +#include > +#include > +#include #include > +#include #include > + > +#include > + > +#include > + > +#include > + > +// > +// Address, Length of the pre-allocated buffer for communication with > +the secure // world. > +// > +STATIC ARM_MEMORY_REGION_DESCRIPTOR mNsCommBuffMemRegion; > + > +// Notification event when virtual address map is set. > +STATIC EFI_EVENT mSetVirtualAddressMapEvent; > + > +// > +// Handle to install the MM Communication Protocol // STATIC > +EFI_HANDLE mMmCommunicateHandle; > + > +/** > + Communicates with a registered handler. > + > + This function provides an interface to send and receive messages to > + the Standalone MM environment on behalf of UEFI services. This > + function is part of the MM Communication Protocol that may be > + called in physical mode prior to > + SetVirtualAddressMap() and in virtual mode after SetVirtualAddressMap(= ). > + > + @param[in] This The EFI_MM_COMMUNICATION_PROTOCOL > + instance. > + @param[in, out] CommBuffer A pointer to the buffer to convey > + into MMRAM. > + @param[in, out] CommSize The size of the data buffer being > + passed in. This is optional. > + > + @retval EFI_SUCCESS The message was successfully poste= d. > + @retval EFI_INVALID_PARAMETER The CommBuffer was NULL. > + @retval EFI_BAD_BUFFER_SIZE The buffer size is incorrect for t= he MM > + implementation. If this error is > + returned, the MessageLength field = in > + the CommBuffer header or the integ= er > + pointed by CommSize are updated to= reflect > + the maximum payload size the > + implementation can accommodate. > + @retval EFI_ACCESS_DENIED The CommunicateBuffer parameter > + or CommSize parameter, if not omit= ted, > + are in address range that cannot b= e > + accessed by the MM environment > +**/ STATIC EFI_STATUS EFIAPI MmCommunicationCommunicate ( > + IN CONST EFI_MM_COMMUNICATION_PROTOCOL *This, > + IN OUT VOID *CommBuffer, > + IN OUT UINTN *CommSize OPTIONAL > + ) > +{ > + EFI_MM_COMMUNICATE_HEADER *CommunicateHeader; > + ARM_SMC_ARGS CommunicateSmcArgs; > + EFI_STATUS Status; > + UINTN BufferSize; > + > + CommunicateHeader =3D CommBuffer; > + Status =3D EFI_ACCESS_DENIED; > + BufferSize =3D 0; > + > + ZeroMem (&CommunicateSmcArgs, sizeof (ARM_SMC_ARGS)); > + > + // > + // Check parameters > + // > + if (CommBuffer =3D=3D NULL) { > + return EFI_INVALID_PARAMETER; > + } > + > + // If the length of the CommBuffer is 0 then return the expected lengt= h. > + if (CommSize) { > + if (*CommSize =3D=3D 0) { > + *CommSize =3D mNsCommBuffMemRegion.Length; > + return EFI_BAD_BUFFER_SIZE; > + } > + // > + // CommSize must hold HeaderGuid and MessageLength > + // > + if (*CommSize < sizeof (EFI_MM_COMMUNICATE_HEADER)) { > + return EFI_INVALID_PARAMETER; > + } The check looks inadequate as it does not cater for the MessageLength speci= fied in the EFI_MM_COMMUNICATE_HEADER i.e it will ensure there is at least = a EFI_MM_COMMUNICATE_HEADER but will not ensure that the message is include= d as well. Nit: It would be better if the parameters are checked before Status and Com= municateSmcArgs are updated above. [Supreeth] As discussed, I will be relying on CommunicateHeader->MessageLen= gth + Sizeof (Header) to calculate total size of communication payload as CommBuffer is a Mandatory parameter as opposed to CommSize which is optiona= l. I have revamped the logic completely. Please check version 2. > + BufferSize =3D *CommSize; > + } else { > + BufferSize =3D CommunicateHeader->MessageLength + > + sizeof (CommunicateHeader->HeaderGuid) + > + sizeof (CommunicateHeader->MessageLength); > + } > + > + // > + // If the buffer size is 0 or greater than what can be tolerated by > + the MM // environment then return the expected size. > + // > + if ((BufferSize =3D=3D 0) || > + (BufferSize > mNsCommBuffMemRegion.Length)) { > + CommunicateHeader->MessageLength =3D mNsCommBuffMemRegion.Length - > + sizeof (CommunicateHeader->Header= Guid) - > + sizeof (CommunicateHeader->Messag= eLength); > + return EFI_BAD_BUFFER_SIZE; > + } The 'if' condition works as expected to return the maximum buffer size if '= CommSize' is NULL. When 'CommSize' is used and the 'BufferSize' (derived fr= om 'CommSize') is greater than what can be tolerated, then it is 'CommSize' th= at must be updated as per the PI spec. but the 'if'condition will still upd= ate the MessageLength. [Supreeth] PI specification does not say MessageLength should not be update= d either. I have revamped the logic completely. Please check version 2. I plan to submit ECR w.r.t MessageLength. > + > + // SMC Function ID > + CommunicateSmcArgs.Arg0 =3D ARM_SMC_ID_MM_COMMUNICATE_AARCH64; > + > + // Reserved for Future. Must be Zero. > + CommunicateSmcArgs.Arg1 =3D 0; > + > + if (mNsCommBuffMemRegion.VirtualBase) { > + CopyMem ((VOID *)mNsCommBuffMemRegion.VirtualBase, CommBuffer, > + BufferSize); } else { > + return EFI_ACCESS_DENIED; > + } VirtualBase was set to PhysicalBase in MmCommunicationInitialize(). Is ther= e any reason why it would be unset here apart from a corruption of mNsCommB= uffMemRegion structure? If not, then this is a panic condition. It is not t= he caller's fault and returning EFI_ACCESS_DENIED does not really help. [Supreeth] This is not a critical event to affect to stop the working syste= m in entirety. If there is a critical failure, Secure side should anyway reset the system. The "if" condition was added as= a result of someone else's feedback from earlier version of the patches. I realize this is an extra check and I have removed this "if" condition. > + > + // For the SMC64 version, this parameter is a 64-bit Physical > + Address (PA) // or Intermediate Physical Address (IPA). > + // For the SMC32 version, this parameter is a 32-bit PA or IPA. > + CommunicateSmcArgs.Arg2 =3D (UINTN)mNsCommBuffMemRegion.PhysicalBase; > + > + // comm_size_address is a PA or an IPA that holds the size of the > + // communication buffer being passed in. This parameter is optional > + // and can be omitted by passing a zero. > + // ARM does not recommend using it since this might require the // > + implementation to create a separate memory mapping for the parameter. > + // ARM recommends storing the buffer size in the buffer itself. > + CommunicateSmcArgs.Arg3 =3D 0; > + > + // Call the Standalone MM environment. > + ArmCallSmc (&CommunicateSmcArgs); > + > + switch (CommunicateSmcArgs.Arg0) { > + case ARM_SMC_MM_RET_SUCCESS: > + // On exit, the size of data being returned is inferred from > + // CommSize or MessageLength + Header. > + CopyMem (CommBuffer, > + (const VOID *)mNsCommBuffMemRegion.VirtualBase, > + BufferSize); Umm! I vaguely remember we had a chat about this but this does not seem rig= ht. The PI spec. does not help by being vague about how data should be copi= ed out and its length reported. However, here is my take. If CommSize is used, then it must be updated by the handler with the size o= f the data returned, zero otherwise. This is as far as the PI spec. goes in= this regard. Even though the spec. does not say this, if CommSize is not used then, Mess= ageLength in the EFI_MM_COMMUNICATE_HEADER must be updated. This also means= that the handler has to preserve the EFI_MM_COMMUNICATE_HEADER in the Comm= Buffer in the return path (again something the PI spec. does not say). In the SMC ABI, CommSize maps to comm_size_address. We do not use this. So = we must rely on the MessageLength on the way back. Using BufferSize does not seem right to me. We are screwed if the input siz= e is not equal to the output size. It is better to retrieve this informatio= n from the MessageLength as the comment says. [Supreeth] As per our previous discussion, You had mentioned that "Variable= Dxe" that uses this driver assumes input size equal to output size. However= , After looking into this further, there are other drivers that consume this and for those drivers input size = is not equal to output size. When input size is not equal to output size, this may lead to overflow issu= es. PI specification does not provide any guidance regarding this. I plan t= o submit an ECR along the below lines. // Note: Very important to ensure that the consumer of this driver // has allocated CommBuffer sufficiently so that the return data // can be copied. Otherwise, this will lead to buffer overflow. // Assumption: CommBuffer =3D malloc (mNsCommBuffMemRegion.Length) // This guidance should be in the PI specification. TODO: ECR. > + Status =3D EFI_SUCCESS; > + break; > + > + case ARM_SMC_MM_RET_NOT_SUPPORTED: NOT_SUPPORTED means that MM_COMMUNICATE is not implemented which must not b= e the case if we are here. MmCommunicationInitialize() must call MM_VERSION= to check this. In fact, the MM interface specification should be updated t= o remove NOT_SUPPORTED for MM_COMMUNICATE if MM_VERSION is implemented. Can you panic() if this is returned? [Supreeth] This is not a critical event to affect to stop the working syste= m in entirety. If there is a critical failure, Secure side should anyway re= set the system. I have removed this case. > + case ARM_SMC_MM_RET_INVALID_PARAMS: > + Status =3D EFI_INVALID_PARAMETER; > + break; > + > + case ARM_SMC_MM_RET_DENIED: > + Status =3D EFI_ACCESS_DENIED; > + break; > + > + case ARM_SMC_MM_RET_NO_MEMORY: > + // Unexpected error since the CommSize was checked for zero length > + // prior to issuing the SMC > + default: > + Status =3D EFI_ACCESS_DENIED; > + ASSERT (0); > + } > + > + return Status; > +} > + > +// > +// MM Communication Protocol instance // > +EFI_MM_COMMUNICATION_PROTOCOL mMmCommunication =3D { > + MmCommunicationCommunicate > +}; > + > +/** > + Notification callback on SetVirtualAddressMap event. > + > + This function notifies the MM communication protocol interface on > + SetVirtualAddressMap event and converts pointers used in this driver > + from physical to virtual address. > + > + @param Event SetVirtualAddressMap event. > + @param Context A context when the SetVirtualAddressMap trigger= ed. > + > + @retval EFI_SUCCESS The function executed successfully. > + @retval Other Some error occurred when executing this functio= n. > + > +**/ > +STATIC > +VOID > +EFIAPI > +NotifySetVirtualAddressMap ( > + IN EFI_EVENT Event, > + IN VOID *Context > + ) > +{ > + EFI_STATUS Status; > + > + Status =3D gRT->ConvertPointer (EFI_OPTIONAL_PTR, > + (VOID **)&mNsCommBuffMemRegion.VirtualBa= se > + ); > + if (EFI_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "NotifySetVirtualAddressMap():" > + " Unable to convert MM runtime pointer. Status:0x%r\n", > + Status)); } > + > +} > + > +/** > + The Entry Point for MM Communication > + > + This function installs the MM communication protocol interface and > + finds out what type of buffer management will be required prior to > + invoking the communication SMC. > + > + @param ImageHandle The firmware allocated handle for the EFI image= . > + @param SystemTable A pointer to the EFI System Table. > + > + @retval EFI_SUCCESS The entry point is executed successfully. > + @retval Other Some error occurred when executing this entry p= oint. > + > +**/ > +EFI_STATUS > +EFIAPI > +MmCommunicationInitialize ( > + IN EFI_HANDLE ImageHandle, > + IN EFI_SYSTEM_TABLE *SystemTable > + ) > +{ > + EFI_STATUS Status; > + > + mNsCommBuffMemRegion.PhysicalBase =3D PcdGet64 (PcdMmBufferBase); // > + During boot , Virtual and Physical are same > + mNsCommBuffMemRegion.VirtualBase =3D > + mNsCommBuffMemRegion.PhysicalBase; > + mNsCommBuffMemRegion.Length =3D PcdGet64 (PcdMmBufferSize); > + > + if (mNsCommBuffMemRegion.PhysicalBase =3D=3D 0) { > + DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: " > + "Invalid MM Buffer Base Address.\n")); > + goto ReturnErrorStatus; > + } > + We need to call MM_VERSION to check whether there is a StandaloneMm imp. in= the Secure world or not. [Supreeth] Agreed. Please see version 2. > + if (mNsCommBuffMemRegion.Length =3D=3D 0) { > + DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: " > + "Maximum Buffer Size is zero.\n")); > + goto ReturnErrorStatus; > + } > + > + Status =3D gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, > + mNsCommBuffMemRegion.PhysicalBase, > + mNsCommBuffMemRegion.Length, > + EFI_MEMORY_WB | > + EFI_MEMORY_XP | > + EFI_MEMORY_RUNTIME); if (EFI_ERROR > + (Status)) { > + DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: " > + "Failed to add MM-NS Buffer Memory Space\n")); > + goto ReturnErrorStatus; > + } > + > + Status =3D gDS->SetMemorySpaceAttributes(mNsCommBuffMemRegion.Physical= Base, > + mNsCommBuffMemRegion.Length, > + EFI_MEMORY_WB | > + EFI_MEMORY_XP); if (EFI_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: " > + "Failed to set MM-NS Buffer Memory attributes\n")); > + goto CleanAddedMemorySpace; > + } > + > + Status =3D gBS->AllocatePages (AllocateAddress, > + EfiRuntimeServicesData, > + EFI_SIZE_TO_PAGES (mNsCommBuffMemRegion.L= ength), > + &mNsCommBuffMemRegion.PhysicalBase); > + if (EFI_ERROR (Status)) { > + DEBUG ((DEBUG_ERROR, "MmCommunicateInitialize: " > + "Failed to allocate MM-NS Buffer Memory Space\n")); > + goto CleanAddedMemorySpace; > + } > + > + // Install the communication protocol Status =3D > + gBS->InstallProtocolInterface (&mMmCommunicateHandle, > + &gEfiMmCommunicationProtocolGu= id, > + EFI_NATIVE_INTERFACE, > + &mMmCommunication); if > + (EFI_ERROR(Status)) { > + DEBUG ((DEBUG_ERROR, "MmCommunicationInitialize: " > + "Failed to install MM communication protocol\n")); > + goto CleanAllocatedPages; > + } > + > + // Register notification callback when virtual address is > + associated // with the physical address. > + // Create a Set Virtual Address Map event. > + // > + Status =3D gBS->CreateEvent (EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE, // Ty= pe > + TPL_NOTIFY, // Noti= fyTpl > + NotifySetVirtualAddressMap, // Noti= fyFunction > + NULL, // Noti= fyContext > + &mSetVirtualAddressMapEvent // Even= t > + ); > + if (Status =3D=3D EFI_SUCCESS) { > + return Status; > + } > + > + gBS->UninstallProtocolInterface(mMmCommunicateHandle, > + &gEfiMmCommunicationProtocolGuid, > + &mMmCommunication); > + > +CleanAllocatedPages: > + gBS->FreePages (mNsCommBuffMemRegion.PhysicalBase, > + EFI_SIZE_TO_PAGES (mNsCommBuffMemRegion.Length)); > + > +CleanAddedMemorySpace: > + gDS->RemoveMemorySpace (mNsCommBuffMemRegion.PhysicalBase, > + mNsCommBuffMemRegion.Length); > + > +ReturnErrorStatus: > + return EFI_INVALID_PARAMETER; > +} > diff --git a/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > new file mode 100644 > index 0000000000..344d55f333 > --- /dev/null > +++ b/ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf > @@ -0,0 +1,50 @@ > +#/** @file > +# > +# DXE MM Communicate driver > +# > +# Copyright (c) 2016 - 2017, ARM Limited. All rights reserved. > +# > +# This program and the accompanying materials # are licensed and > +made available under the terms and conditions of the BSD License # > +which accompanies this distribution. The full text of the license > +may be found at # http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > +BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPR= ESS OR IMPLIED. > +# > +#**/ > + > +[Defines] > + INF_VERSION =3D 0x0001001A > + BASE_NAME =3D ArmMmCommunication > + FILE_GUID =3D 09EE81D3-F15E-43F4-85B4-CB9873DA5D6= B > + MODULE_TYPE =3D DXE_RUNTIME_DRIVER > + VERSION_STRING =3D 1.0 > + > + ENTRY_POINT =3D MmCommunicationInitialize > + > +[Sources.Common] > + MmCommunication.c Since this is a AArch64 only driver. Should it not be under Sources.Common.= AArch64? [Supreeth] It is in ArmPkg, so it implies it's a 32 bit or AArch64 driver,= but as an added measure, I will move it under Sources. AArch64 and not Sou= rces.Common.AArch64. (to be pedantic) Cheers, Achin > + > +[Packages] > + ArmPkg/ArmPkg.dec > + MdePkg/MdePkg.dec > + > +[LibraryClasses] > + ArmLib > + ArmSmcLib > + BaseMemoryLib > + DebugLib > + DxeServicesTableLib > + HobLib > + UefiDriverEntryPoint > + > +[Protocols] > + gEfiMmCommunicationProtocolGuid ## PRODUCES > + > +[Pcd.common] > + gArmTokenSpaceGuid.PcdMmBufferBase > + gArmTokenSpaceGuid.PcdMmBufferSize > + > +[Depex] > + AFTER gArmGicDxeFileGuid > -- > 2.16.2 > IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.