From: "Wang, Jian J" <jian.j.wang@intel.com>
To: "Ni, Ruiyu" <ruiyu.ni@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Dong, Eric" <eric.dong@intel.com>
Subject: Re: [PATCH] UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory
Date: Sat, 3 Mar 2018 01:31:43 +0000 [thread overview]
Message-ID: <D827630B58408649ACB04F44C510003624D03920@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <04d43b92-5697-2561-e672-600caa518141@Intel.com>
Regards,
Jian
> -----Original Message-----
> From: Ni, Ruiyu
> Sent: Friday, March 02, 2018 7:58 PM
> To: Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>;
> edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.dong@intel.com>
> Subject: Re: [PATCH] UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in
> executable memory
>
> On 3/2/2018 7:45 PM, Laszlo Ersek wrote:
> > On 03/02/18 06:58, Jian J Wang wrote:
> >> if PcdDxeNxMemoryProtectionPolicy is enabled for EfiReservedMemoryType
> >> of memory, #PF will be triggered for each APs after ExitBootServices
> >> in SCRT test. The root cause is that AP wakeup code executed at that
> >> time is stored in memory of type EfiReservedMemoryType (referenced by
> >> global mReservedApLoopFunc), which is marked as non-executable.
> >>
> >> This patch fixes this issue by setting memory of mReservedApLoopFunc to
> >> be executable immediately after allocation.
> >>
> >> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> >> Cc: Eric Dong <eric.dong@intel.com>
> >> Cc: Laszlo Ersek <lersek@redhat.com>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
> >> ---
> >> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 15 +++++++++++++++
> >> 1 file changed, 15 insertions(+)
> >>
> >> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> >> index fd2317924f..5fcb08677c 100644
> >> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> >> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> >> @@ -399,6 +399,21 @@ InitMpGlobalData (
> >> &Address
> >> );
> >> ASSERT_EFI_ERROR (Status);
> >> +
> >> + //
> >> + // Make sure that the buffer memory is executable.
> >> + //
> >> + Status = gDS->GetMemorySpaceDescriptor (Address, &MemDesc);
> >> + if (!EFI_ERROR (Status)) {
> >> + gDS->SetMemorySpaceAttributes (
> >> + Address,
> >> + EFI_PAGES_TO_SIZE (EFI_SIZE_TO_PAGES (
> >> + CpuMpData->AddressMap.RelocateApLoopFuncSize
> >> + )),
> >> + MemDesc.Attributes & (~EFI_MEMORY_XP)
> >> + );
> >> + }
> >> +
> >> mReservedApLoopFunc = (VOID *) (UINTN) Address;
> >> ASSERT (mReservedApLoopFunc != NULL);
> >> mReservedTopOfApStack = (UINTN) Address + EFI_PAGES_TO_SIZE
> (EFI_SIZE_TO_PAGES (ApSafeBufferSize));
> >>
> >
> > Honestly, I see little point in the "Dxe Nx Memory Protection Policy"
> > when we then override it *every time* it gets in our way.
> > "RelocateApLoopFuncSize" is likely significantly smaller than a full
> > page, so we're making a good chunk of the "safe stack(s)" executable too.
> >
> > Anyway, can you perhaps check BIT0 (standing for EfiReservedMemoryType)
> > in PcdDxeNxMemoryProtectionPolicy, to see if the above hack is necessary?
> >
> > Thanks
> > Laszlo
> >
>
> Checking PCD is not very good I think.
> If checking is really needed, how about check MemDesc.Attributes
> EFI_MEMORY_XP bit?
>
>
a. Page attributes update has to be in page unit. If we want to avoid making stack
memory executable, reserving it in a separate memory page is the only way I can
think of.
b. Checking MemDesc.Attributes against EFI_MEMORY_XP doesn't work here. The
reason is that EFI_MEMORY_XP is set to configured type of memory via CPU Arch
protocol in DxeCore code, which won't be recorded in GCD service data. Maybe
checking PCD BIT0 is the only way according current situation.
> --
> Thanks,
> Ray
next prev parent reply other threads:[~2018-03-03 1:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 5:58 [PATCH] UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory Jian J Wang
2018-03-02 11:45 ` Laszlo Ersek
2018-03-02 11:57 ` Ni, Ruiyu
2018-03-03 1:31 ` Wang, Jian J [this message]
2018-03-03 7:08 ` Ni, Ruiyu
2018-03-03 8:10 ` Wang, Jian J
2018-03-03 9:01 ` Wang, Jian J
2018-03-03 15:10 ` Laszlo Ersek
2018-03-05 5:06 ` Ni, Ruiyu
-- strict thread matches above, loose matches on Subject: below --
2018-03-03 9:02 Jian J Wang
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=D827630B58408649ACB04F44C510003624D03920@SHSMSX103.ccr.corp.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