public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Jian J Wang <jian.j.wang@intel.com>
To: edk2-devel@lists.01.org
Cc: Eric Dong <eric.dong@intel.com>, Jiewen Yao <jiewen.yao@intel.com>
Subject: [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
Date: Wed, 25 Oct 2017 16:12:42 +0800	[thread overview]
Message-ID: <20171025081242.1340-1-jian.j.wang@intel.com> (raw)

> v2 just updated the commit message.

Multiple RT_CODE in memory map was introduced by previous commit

    c1cab54ce57c2608b8b3ea051c7041f036f21153

This commit changed memory capability only based on page type of memory
attributes. EDK2's report of memory map to OS is grouped by memory
capabilites. This will cause more than on RT_CODE entries in memory map
if UEFI image protection is enabled, which will mark memory of code
segments of some modules to be read-only.

More than one entry of RT_CODE memory will cause boot problem for specific
old version of Linux kernel, because it will misplace the code segment and
data segment in this situation. The recent major Linux distro have no such
problem in boot. This patch will fix this issue to keep OS compatibility
as much as possible.

>From memory paging point of view, all memory block should have the capabilites
to change paging related memory attributes, if the memory paging has been
enabled and well setup, not just those memory blocks having some paging related
attributes set. So this patch will simply add all paging related memory
attribtes to the capability of all existing memory blocks if paging is enabled.
As a side effect, it will prevent EDK2 from reporting multple RT_CODE to OS.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
---
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index d312eb66f8..0802464b9d 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -829,6 +829,15 @@ RefreshGcdMemoryAttributesFromPaging (
     // Sync real page attributes to GCD
     BaseAddress       = MemorySpaceMap[Index].BaseAddress;
     MemorySpaceLength = MemorySpaceMap[Index].Length;
+    Capabilities      = MemorySpaceMap[Index].Capabilities |
+                        EFI_MEMORY_PAGETYPE_MASK;
+    Status = gDS->SetMemorySpaceCapabilities (
+                    BaseAddress,
+                    MemorySpaceLength,
+                    Capabilities
+                    );
+    ASSERT_EFI_ERROR (Status);
+
     while (MemorySpaceLength > 0) {
       if (PageLength == 0) {
         PageEntry = GetPageTableEntry (&PagingContext, BaseAddress, &PageAttribute);
@@ -846,7 +855,6 @@ RefreshGcdMemoryAttributesFromPaging (
         if (Attributes != (MemorySpaceMap[Index].Attributes & EFI_MEMORY_PAGETYPE_MASK)) {
           DoUpdate = TRUE;
           Attributes |= (MemorySpaceMap[Index].Attributes & ~EFI_MEMORY_PAGETYPE_MASK);
-          Capabilities = Attributes | MemorySpaceMap[Index].Capabilities;
         } else {
           DoUpdate = FALSE;
         }
@@ -854,8 +862,8 @@ RefreshGcdMemoryAttributesFromPaging (
 
       Length = MIN (PageLength, MemorySpaceLength);
       if (DoUpdate) {
-        gDS->SetMemorySpaceCapabilities (BaseAddress, Length, Capabilities);
-        gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attributes);
+        Status = gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attributes);
+        ASSERT_EFI_ERROR (Status);
         DEBUG ((DEBUG_INFO, "Update memory space attribute: [%02d] %016lx - %016lx (%08lx -> %08lx)\r\n",
                              Index, BaseAddress, BaseAddress + Length - 1,
                              MemorySpaceMap[Index].Attributes, Attributes));
-- 
2.14.1.windows.1



             reply	other threads:[~2017-10-25  8:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25  8:12 Jian J Wang [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-11-03  0:57 [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map Jian J Wang
2017-11-06  9:15 ` Zeng, Star
2017-11-07  0:55   ` Wang, Jian J
2017-11-07  1:12     ` Zeng, Star
2017-11-08  3:13     ` Zeng, Star
2017-11-08 13:25       ` Laszlo Ersek
2017-11-07 17:13 ` Laszlo Ersek
2017-11-08  0:10   ` Wang, Jian J
2017-11-08  9:10     ` Wang, Jian J
2017-11-08 14:17     ` Laszlo Ersek
2017-11-09  0:41       ` Wang, Jian J
2017-11-09  1:48         ` Yao, Jiewen
2017-11-09  1:51           ` Wang, Jian J
2017-11-09 12:19           ` Laszlo Ersek
2017-11-08  4:41 ` Ni, Ruiyu
2017-11-08  4:46   ` Wang, Jian J

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=20171025081242.1340-1-jian.j.wang@intel.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