public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Achin Gupta <achin.gupta@arm.com>
To: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: edk2-devel@lists.01.org, michael.d.kinney@intel.com,
	liming.gao@intel.com, jiewen.yao@intel.com,
	leif.lindholm@linaro.org, ard.biesheuvel@linaro.org, nd@arm.com
Subject: Re: [PATCH v1 04/18] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0.
Date: Wed, 11 Apr 2018 20:21:53 +0100	[thread overview]
Message-ID: <20180411192153.GH663@e104320-lin> (raw)
In-Reply-To: <20180406144223.10931-5-supreeth.venkatesh@arm.com>

Hi Supreeth,

On Fri, Apr 06, 2018 at 03:42:09PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms. Privileged firmware e.g. ARM Trusted Firmware sets up its
> architectural context including the initial translation tables for the
> S-EL1/EL0 translation regime. The MM environment could still request ARM
> TF to change the memory attributes of memory regions during
> initialization.

The commit message needs more detail to better flesh out why we are doing what
we are doing here i.e. the StandaloneMm image is a FV that encapsulates the MM
foundation and drivers. These are PE-COFF images with data and text
segments. Arm TF does not have visibility of the contents of the FV. Moreover,
the driver images are relocated upon dispatch. However, to initialise the MM
environment, Arm TF has to create translation tables with sane default
attributes for the memory occupied by the FV............

I am hoping you can extrapolate from here and clearly describe what problem this
library solves.

> 
> This patch adds a simple MMU library suitable for execution in S-EL0 and
> requesting operations from higher exception levels.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Achin Gupta <achin.gupta@arm.com>
> Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
> ---
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c | 146 ++++++++++++++++++++++++
>  1 file changed, 146 insertions(+)
>  create mode 100644 ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c

I am not sure about the name of the library. ArmMmuSecLib sounds like an MMU
library for the SEC phase in the Normal world. Can we call it
ArmMmuSecStandaloneMmLib or similar.

> new file mode 100644
> index 0000000000..56969e31d1
> --- /dev/null
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuSecLib.c
> @@ -0,0 +1,146 @@
> +/** @file
> +*  File managing the MMU for ARMv8 architecture in S-EL0
> +*
> +*  Copyright (c) 2017, ARM Limited. All rights reserved.

Nit: Copyright 2018? For this and other files?

> +*
> +*  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 EXPRESS OR IMPLIED.
> +*
> +**/
> +
> +#include <Uefi.h>
> +#include <Chipset/AArch64.h>
> +#include <IndustryStandard/ArmMmSvc.h>
> +
> +#include <Library/ArmLib.h>
> +#include <Library/ArmMmuLib.h>
> +#include <Library/ArmSvcLib.h>
> +#include <Library/BaseLib.h>
> +#include <Library/DebugLib.h>
> +
> +EFI_STATUS
> +RequestMemoryPermissionChange(
> +  IN  EFI_PHYSICAL_ADDRESS      BaseAddress,
> +  IN  UINT64                    Length,
> +  IN  UINTN                     Permissions
> +  )
> +{
> +  EFI_STATUS    Status;
> +  ARM_SVC_ARGS  ChangeMemoryPermissionsSvcArgs = {0};
> +
> +  ChangeMemoryPermissionsSvcArgs.Arg0 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
> +  ChangeMemoryPermissionsSvcArgs.Arg1 = BaseAddress;
> +  ChangeMemoryPermissionsSvcArgs.Arg2 = (Length >= EFI_PAGE_SIZE) ? \
> +                                         Length >> EFI_PAGE_SHIFT : 1;
> +  ChangeMemoryPermissionsSvcArgs.Arg3 = Permissions;
> +
> +  ArmCallSvc(&ChangeMemoryPermissionsSvcArgs);
> +
> +  Status = ChangeMemoryPermissionsSvcArgs.Arg0;
> +
> +  switch (Status) {
> +  case ARM_SVC_SPM_RET_SUCCESS:
> +    Status = EFI_SUCCESS;
> +    break;
> +
> +  case ARM_SVC_SPM_RET_NOT_SUPPORTED:
> +    Status = EFI_UNSUPPORTED;
> +    break;
> +
> +  case ARM_SVC_SPM_RET_INVALID_PARAMS:
> +    Status = EFI_INVALID_PARAMETER;
> +    break;
> +
> +  case ARM_SVC_SPM_RET_DENIED:
> +    Status = EFI_ACCESS_DENIED;
> +    break;
> +
> +  case ARM_SVC_SPM_RET_NO_MEMORY:
> +    Status = EFI_BAD_BUFFER_SIZE;
> +    break;
> +
> +  default:
> +    Status = EFI_ACCESS_DENIED;
> +    ASSERT (0);
> +  }
> +
> +  return Status;
> +}
> +
> +EFI_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS      BaseAddress,
> +  IN  UINT64                    Length
> +  )
> +{
> +  return RequestMemoryPermissionChange(BaseAddress,
> +                                       Length,
> +                                       SET_MEM_ATTR_MAKE_PERM_REQUEST( \
> +                                         SET_MEM_ATTR_DATA_PERM_RO, \
> +                                         SET_MEM_ATTR_CODE_PERM_XN));
> +}
> +
> +EFI_STATUS
> +ArmClearMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS      BaseAddress,
> +  IN  UINT64                    Length
> +  )
> +{
> +  return RequestMemoryPermissionChange(BaseAddress,
> +                                       Length,
> +                                       SET_MEM_ATTR_MAKE_PERM_REQUEST( \
> +                                         SET_MEM_ATTR_DATA_PERM_RO, \
> +                                         SET_MEM_ATTR_CODE_PERM_X));
> +}
> +
> +EFI_STATUS
> +ArmSetMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS      BaseAddress,
> +  IN  UINT64                    Length
> +  )
> +{
> +  return RequestMemoryPermissionChange(BaseAddress,
> +                                       Length,
> +                                       SET_MEM_ATTR_MAKE_PERM_REQUEST( \
> +                                         SET_MEM_ATTR_DATA_PERM_RO, \
> +                                         SET_MEM_ATTR_CODE_PERM_XN));
> +}
> +
> +EFI_STATUS
> +ArmClearMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS      BaseAddress,
> +  IN  UINT64                    Length
> +  )
> +{
> +  return RequestMemoryPermissionChange(BaseAddress,
> +                                       Length,
> +                                       SET_MEM_ATTR_MAKE_PERM_REQUEST( \
> +                                         SET_MEM_ATTR_DATA_PERM_RW, \
> +                                         SET_MEM_ATTR_CODE_PERM_XN));
> +}

The above four functions were written as prototypes in the edk2-staging
branch. I do not think they are adequate for upstreaming since each function
makes assumptions about the current data or instruction access permission of the
input memory region instead of only doing what the function's name suggests.

For example, ArmSetMemoryRegionNoExec() is supposed to only set the XN
bit. However, it also sets the data access permission to RO. If the region was
RW then this will lead to incorrect behaviour. Ditto for the other functions.

We need a GetMemoryPermission() function that first uses the
ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64 call to obtain the memory attributes of
the input region. Each of the above functions must use this new function and
only change the data or instruction permission attribute as appropriate.

cheers,
Achin

> +
> +EFI_STATUS
> +EFIAPI
> +ArmConfigureMmu (
> +  IN  ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable,
> +  OUT VOID                          **TranslationTableBase OPTIONAL,
> +  OUT UINTN                         *TranslationTableSize OPTIONAL
> +  )
> +{
> +  return EFI_UNSUPPORTED;
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +ArmMmuSecLibConstructor (
> +  IN EFI_HANDLE            ImageHandle,
> +  IN EFI_MM_SYSTEM_TABLE   *MmSystemTable
> +  )
> +{
> +  return EFI_SUCCESS;
> +}
> -- 
> 2.16.2
> 


  reply	other threads:[~2018-04-11 19:20 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 14:42 [PATCH v1 00/18] *** Standalone Management Mode Core Interface for AARCH64 Platforms *** Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 01/18] ArmPkg: Add PCDs needed for MM communication driver Supreeth Venkatesh
2018-04-11 14:43   ` Achin Gupta
     [not found]     ` <AM4PR0802MB23063743A3B2F5A552BE320580870@AM4PR0802MB2306.eurprd08.prod.outlook.com>
2018-05-04 23:13       ` Supreeth Venkatesh
2018-05-04 23:17     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 02/18] ArmPkg/Drivers: Add EFI_MM_COMMUNICATION_PROTOCOL DXE driver Supreeth Venkatesh
2018-04-11 14:00   ` Achin Gupta
2018-05-04 23:18     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 03/18] ArmPkg/Include: Add MM interface SVC return codes Supreeth Venkatesh
2018-04-11 14:38   ` Achin Gupta
2018-05-04 23:19     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 04/18] ArmPkg/ArmMmuLib: Add MMU Library suitable for use in S-EL0 Supreeth Venkatesh
2018-04-11 19:21   ` Achin Gupta [this message]
2018-05-04 23:19     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 05/18] ArmPkg/ArmMmuLib: Add MMU library inf file " Supreeth Venkatesh
2018-04-11 19:24   ` Achin Gupta
2018-05-04 23:19     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 06/18] StandaloneMmPkg: Add an AArch64 specific entry point library Supreeth Venkatesh
2018-04-16 14:04   ` Achin Gupta
2018-05-04 23:20     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 07/18] StandaloneMmPkg/FvLib: Add a common FV Library for management mode Supreeth Venkatesh
2018-04-16 14:44   ` Achin Gupta
2018-05-04 23:21     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 08/18] StandaloneMmPkg/MemLib: AARCH64 Specific instance of memory check library Supreeth Venkatesh
2018-04-16 15:12   ` Achin Gupta
2018-04-16 22:30     ` Yao, Jiewen
2018-04-25 10:35       ` Achin Gupta
2018-04-26 13:02         ` Yao, Jiewen
2018-05-04 23:21     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 09/18] StandaloneMmPkg/MemoryAllocationLib: Add MM memory allocation library Supreeth Venkatesh
2018-04-25 14:33   ` Achin Gupta
2018-04-26 13:05     ` Yao, Jiewen
2018-05-04 23:23       ` Supreeth Venkatesh
2018-05-04 23:21     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 10/18] StandaloneMmPkg/HobLib: Add AARCH64 Specific HOB Library for management mode Supreeth Venkatesh
2018-04-25 14:50   ` Achin Gupta
2018-04-26 13:04     ` Yao, Jiewen
2018-05-04 23:22       ` Supreeth Venkatesh
2018-05-04 23:25     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 11/18] StandaloneMmPkg: MM driver entry point library Supreeth Venkatesh
2018-04-30 14:29   ` Achin Gupta
2018-05-04 23:24     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 12/18] StandaloneMmPkg/CpuMm: Add CPU driver suitable for ARM Platforms Supreeth Venkatesh
2018-04-18 22:09   ` Daniil Egranov
2018-05-04 23:25     ` Supreeth Venkatesh
2018-04-30 15:50   ` Achin Gupta
2018-05-04 23:24     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 13/18] StandaloneMmPkg/Core: Implementation of Standalone MM Core Module Supreeth Venkatesh
2018-04-30 19:19   ` Achin Gupta
2018-04-30 19:28     ` Ard Biesheuvel
2018-04-30 20:17       ` Achin Gupta
2018-05-01  8:18       ` Laszlo Ersek
2018-05-04 23:28     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 14/18] StandaloneMmPkg: Describe the declaration, definition and fdf files Supreeth Venkatesh
2018-04-18 19:50   ` Daniil Egranov
2018-05-04 23:29     ` Supreeth Venkatesh
2018-04-30 19:32   ` Achin Gupta
2018-05-04 23:28     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 15/18] ArmPkg: Extra action to update permissions for S-ELO MM Image Supreeth Venkatesh
2018-04-30 19:49   ` Achin Gupta
2018-05-04 23:30     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 16/18] BaseTools/AutoGen: Update header file for MM modules Supreeth Venkatesh
2018-04-30 19:52   ` Achin Gupta
2018-05-04 23:30     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 17/18] StandaloneMmPkg: Add application to test MM communication protocol Supreeth Venkatesh
2018-04-30 20:02   ` Achin Gupta
2018-05-04 23:31     ` Supreeth Venkatesh
2018-04-06 14:42 ` [PATCH v1 18/18] StandaloneMmPkg: Add handler to handle event received from Normal World Supreeth Venkatesh
2018-04-08  6:01 ` [PATCH v1 00/18] *** Standalone Management Mode Core Interface for AARCH64 Platforms *** Yao, Jiewen
2018-05-04 23:15   ` Supreeth Venkatesh

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=20180411192153.GH663@e104320-lin \
    --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