public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Sunil V L" <sunilvl@ventanamicro.com>
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Andrei Warkentin <andrei.warkentin@intel.com>
Subject: [PATCH v2 1/1] OvmfPkg/RiscVVirt: Support multiple reserved memory ranges
Date: Mon, 27 Mar 2023 17:49:58 +0530	[thread overview]
Message-ID: <20230327121958.1806982-1-sunilvl@ventanamicro.com> (raw)

M-mode firmware ranges should not be used by EDK2/OS.
Currently, we search for mmode_resv0 node in FDT and mark it as the
reserved memory in EFI memory map. However, if there are multiple
M-mode firmware ranges, then this will miss those extra ranges
allowing the OS to access the memory and hit a fault.

This issue is exposed since recent opensbi started creating
two ranges for text and data.

Fix this by searching for all reserved memory nodes and marking
them as reserved in the EFI memory map.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
---
Changes since v1:
	1) Updated IN/OUT and function comment as per Andrei's feedback.
	2) Added RB tag

 OvmfPkg/RiscVVirt/Sec/Memory.c | 226 ++++++++++++++++++++++-----------
 1 file changed, 149 insertions(+), 77 deletions(-)

diff --git a/OvmfPkg/RiscVVirt/Sec/Memory.c b/OvmfPkg/RiscVVirt/Sec/Memory.c
index 70935b07b56b..f7a72c7bb4fb 100644
--- a/OvmfPkg/RiscVVirt/Sec/Memory.c
+++ b/OvmfPkg/RiscVVirt/Sec/Memory.c
@@ -38,31 +38,6 @@ BuildMemoryTypeInformationHob (
   VOID
   );
 
-/**
-  Build reserved memory range resource HOB.
-
-  @param  MemoryBase     Reserved memory range base address.
-  @param  MemorySize     Reserved memory range size.
-
-**/
-STATIC
-VOID
-AddReservedMemoryBaseSizeHob (
-  EFI_PHYSICAL_ADDRESS  MemoryBase,
-  UINT64                MemorySize
-  )
-{
-  BuildResourceDescriptorHob (
-    EFI_RESOURCE_MEMORY_RESERVED,
-    EFI_RESOURCE_ATTRIBUTE_PRESENT     |
-    EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
-    EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
-    EFI_RESOURCE_ATTRIBUTE_TESTED,
-    MemoryBase,
-    MemorySize
-    );
-}
-
 /**
   Create memory range resource HOB using the memory base
   address and size.
@@ -74,8 +49,8 @@ AddReservedMemoryBaseSizeHob (
 STATIC
 VOID
 AddMemoryBaseSizeHob (
-  EFI_PHYSICAL_ADDRESS  MemoryBase,
-  UINT64                MemorySize
+  IN EFI_PHYSICAL_ADDRESS  MemoryBase,
+  IN UINT64                MemorySize
   )
 {
   BuildResourceDescriptorHob (
@@ -103,8 +78,8 @@ AddMemoryBaseSizeHob (
 STATIC
 VOID
 AddMemoryRangeHob (
-  EFI_PHYSICAL_ADDRESS  MemoryBase,
-  EFI_PHYSICAL_ADDRESS  MemoryLimit
+  IN EFI_PHYSICAL_ADDRESS  MemoryBase,
+  IN EFI_PHYSICAL_ADDRESS  MemoryLimit
   )
 {
   AddMemoryBaseSizeHob (MemoryBase, (UINT64)(MemoryLimit - MemoryBase));
@@ -132,39 +107,152 @@ InitMmu (
 STATIC
 VOID
 InitializeRamRegions (
-  EFI_PHYSICAL_ADDRESS  SystemMemoryBase,
-  UINT64                SystemMemorySize,
-  EFI_PHYSICAL_ADDRESS  MmodeResvBase,
-  UINT64                MmodeResvSize
+  IN EFI_PHYSICAL_ADDRESS  SystemMemoryBase,
+  IN UINT64                SystemMemorySize
   )
 {
-  /*
-   * M-mode FW can be loaded anywhere in memory but should not overlap
-   * with the EDK2. This can happen if some other boot code loads the
-   * M-mode firmware.
-   *
-   * The M-mode firmware memory should be marked as reserved memory
-   * so that OS doesn't use it.
-   */
-  DEBUG ((
-    DEBUG_INFO,
-    "%a: M-mode FW Memory Start:0x%lx End:0x%lx\n",
-    __FUNCTION__,
-    MmodeResvBase,
-    MmodeResvBase + MmodeResvSize
-    ));
-  AddReservedMemoryBaseSizeHob (MmodeResvBase, MmodeResvSize);
-
-  if (MmodeResvBase > SystemMemoryBase) {
-    AddMemoryRangeHob (SystemMemoryBase, MmodeResvBase);
-  }
-
   AddMemoryRangeHob (
-    MmodeResvBase + MmodeResvSize,
+    SystemMemoryBase,
     SystemMemoryBase + SystemMemorySize
     );
 }
 
+/** Get the number of cells for a given property
+
+  @param[in]  Fdt   Pointer to Device Tree (DTB)
+  @param[in]  Node  Node
+  @param[in]  Name  Name of the property
+
+  @return           Number of cells.
+**/
+STATIC
+INT32
+GetNumCells (
+  IN VOID         *Fdt,
+  IN INT32        Node,
+  IN CONST CHAR8  *Name
+  )
+{
+  CONST INT32  *Prop;
+  INT32        Len;
+  UINT32       Val;
+
+  Prop = fdt_getprop (Fdt, Node, Name, &Len);
+  if (Prop == NULL) {
+    return Len;
+  }
+
+  if (Len != sizeof (*Prop)) {
+    return -FDT_ERR_BADNCELLS;
+  }
+
+  Val = fdt32_to_cpu (*Prop);
+  if (Val > FDT_MAX_NCELLS) {
+    return -FDT_ERR_BADNCELLS;
+  }
+
+  return (INT32)Val;
+}
+
+/** Mark reserved memory ranges in the EFI memory map
+
+  The M-mode firmware ranges should not be used by the
+  EDK2/OS. These ranges are passed via device tree using reserved
+  memory nodes. Parse the DT and mark those ranges as of
+  type EfiReservedMemoryType.
+
+  NOTE: Device Tree spec section 3.5.4 says reserved memory regions
+  without no-map property should be installed as EfiBootServicesData.
+  As per UEFI spec, memory of type EfiBootServicesData can be used
+  by the OS after ExitBootServices().
+  This is not an issue for DT since OS can parse the DT also along
+  with EFI memory map and avoid using these ranges. But with ACPI,
+  there is no such mechanisms possible.
+  Since EDK2 needs to support both DT and ACPI, we are deviating
+  from the DT spec and marking all reserved memory ranges as
+  EfiReservedMemoryType itself irrespective of no-map.
+
+  @param FdtPointer Pointer to FDT
+
+**/
+STATIC
+VOID
+AddReservedMemoryMap (
+  IN VOID  *FdtPointer
+  )
+{
+  CONST INT32           *RegProp;
+  INT32                 Node;
+  INT32                 SubNode;
+  INT32                 Len;
+  EFI_PHYSICAL_ADDRESS  Addr;
+  UINT64                Size;
+  INTN                  NumRsv, i;
+  INT32                 NumAddrCells, NumSizeCells;
+
+  NumRsv = fdt_num_mem_rsv (FdtPointer);
+
+  /* Look for an existing entry and add it to the efi mem map. */
+  for (i = 0; i < NumRsv; i++) {
+    if (fdt_get_mem_rsv (FdtPointer, i, &Addr, &Size) != 0) {
+      continue;
+    }
+
+    BuildMemoryAllocationHob (
+      Addr,
+      Size,
+      EfiReservedMemoryType
+      );
+  }
+
+  /* process reserved-memory */
+  Node = fdt_subnode_offset (FdtPointer, 0, "reserved-memory");
+  if (Node >= 0) {
+    NumAddrCells = GetNumCells (FdtPointer, Node, "#address-cells");
+    if (NumAddrCells <= 0) {
+      return;
+    }
+
+    NumSizeCells = GetNumCells (FdtPointer, Node, "#size-cells");
+    if (NumSizeCells <= 0) {
+      return;
+    }
+
+    fdt_for_each_subnode (SubNode, FdtPointer, Node) {
+      RegProp = fdt_getprop (FdtPointer, SubNode, "reg", &Len);
+
+      if ((RegProp != 0) && (Len == ((NumAddrCells + NumSizeCells) * sizeof (INT32)))) {
+        Addr = fdt32_to_cpu (RegProp[0]);
+
+        if (NumAddrCells > 1) {
+          Addr = (Addr << 32) | fdt32_to_cpu (RegProp[1]);
+        }
+
+        RegProp += NumAddrCells;
+        Size     = fdt32_to_cpu (RegProp[0]);
+
+        if (NumSizeCells > 1) {
+          Size = (Size << 32) | fdt32_to_cpu (RegProp[1]);
+        }
+
+        DEBUG ((
+          DEBUG_INFO,
+          "%a: Adding Reserved Memory Addr = 0x%llx, Size = 0x%llx\n",
+          __func__,
+          Addr,
+          Size
+          ));
+
+        BuildMemoryAllocationHob (
+          Addr,
+          Size,
+          EfiReservedMemoryType
+          );
+      }
+    }
+  }
+}
+
 /**
   Initialize memory hob based on the DTB information.
 
@@ -183,8 +271,6 @@ MemoryPeimInitialization (
   INT32                       Node, Prev;
   INT32                       Len;
   VOID                        *FdtPointer;
-  EFI_PHYSICAL_ADDRESS        MmodeResvBase;
-  UINT64                      MmodeResvSize;
 
   FirmwareContext = NULL;
   GetFirmwareContextPointer (&FirmwareContext);
@@ -200,16 +286,6 @@ MemoryPeimInitialization (
     return EFI_UNSUPPORTED;
   }
 
-  /* try to locate the reserved memory opensbi node */
-  Node = fdt_path_offset (FdtPointer, "/reserved-memory/mmode_resv0");
-  if (Node >= 0) {
-    RegProp = fdt_getprop (FdtPointer, Node, "reg", &Len);
-    if ((RegProp != 0) && (Len == (2 * sizeof (UINT64)))) {
-      MmodeResvBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
-      MmodeResvSize = fdt64_to_cpu (ReadUnaligned64 (RegProp + 1));
-    }
-  }
-
   // Look for the lowest memory node
   for (Prev = 0; ; Prev = Node) {
     Node = fdt_next_node (FdtPointer, Prev, NULL);
@@ -235,16 +311,10 @@ MemoryPeimInitialization (
           CurBase + CurSize - 1
           ));
 
-        if ((MmodeResvBase >= CurBase) && ((MmodeResvBase + MmodeResvSize) <= (CurBase + CurSize))) {
-          InitializeRamRegions (
-            CurBase,
-            CurSize,
-            MmodeResvBase,
-            MmodeResvSize
-            );
-        } else {
-          AddMemoryBaseSizeHob (CurBase, CurSize);
-        }
+        InitializeRamRegions (
+          CurBase,
+          CurSize
+          );
       } else {
         DEBUG ((
           DEBUG_ERROR,
@@ -255,6 +325,8 @@ MemoryPeimInitialization (
     }
   }
 
+  AddReservedMemoryMap (FdtPointer);
+
   InitMmu ();
 
   BuildMemoryTypeInformationHob ();
-- 
2.34.1


                 reply	other threads:[~2023-03-27 12:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20230327121958.1806982-1-sunilvl@ventanamicro.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