From: "Zeng, Star" <star.zeng@intel.com>
To: "Wang, Jian J" <jian.j.wang@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Ni, Ruiyu" <ruiyu.ni@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
Date: Mon, 17 Sep 2018 05:57:07 +0000 [thread overview]
Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103BBBA7A4@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <D827630B58408649ACB04F44C510003624E3554A@SHSMSX103.ccr.corp.intel.com>
How about we see the problem in another way?
If my understanding is correct, current discussion and patches think FALSE/0 means disable/clear NX, but that is not the fact.
According to the code implementation, FALSE/0 seems mean *AS IS* to do thing (no code to disable/clear NX).
PcdSetNxForStack
TRUE: Set NX for stack.
FALSE: No code to clear NX for stack.
PcdDxeNxMemoryProtectionPolicy
BITX 1: Set NX for that memory type.
BITX 0: No code to clear NX for that memory type.
PcdImageProtectionPolicy
BITX 1: Set NX for the image data section.
BITX 0: Not code to clear NX for the image data section.
So, how about we think one PCD just works for itself and it does not impact other PCDs to protect?
That means TRUE/1 is to protect and FALSE/0 is *AS IS* to do nothing.
The description of these PCDs could be enhancement if we think it is a good way to see the problem.
Thanks,
Star
-----Original Message-----
From: Wang, Jian J
Sent: Monday, September 17, 2018 10:11 AM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: RE: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
Laszlo,
Thanks for the comments.
Regards,
Jian
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, September 14, 2018 5:51 PM
> To: Wang, Jian J <jian.j.wang@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>; Yao,
> Jiewen <jiewen.yao@intel.com>
> Subject: Re: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
>
> I've got some comments on the code as well:
>
> On 09/14/18 07:13, Jian J Wang wrote:
> > BZ#1116: https://bugzilla.tianocore.org/show_bug.cgi?id=1116
> >
> > Currently IA32_EFER.NXE is only set against PcdSetNxForStack. This
> > confuses developers because following two other PCDs also need NXE
> > to be set, but actually not.
> >
> > PcdDxeNxMemoryProtectionPolicy
> > PcdImageProtectionPolicy
> >
> > This patch solves this issue by adding logic to enable IA32_EFER.NXE
> > if any of those PCDs have anything enabled.
> >
> > Due to the fact that NX memory type of stack (enabled by
> >PcdSetNxForStack)
> > and image data section (enabled by PcdImageProtectionPolicy) are
> >also
> > part of PcdDxeNxMemoryProtectionPolicy, this patch also add more
> >checks
> > to warn (ASSERT) users any unreasonable setting combinations. For
> >example,
> >
> > PcdSetNxForStack == FALSE &&
> > (PcdDxeNxMemoryProtectionPolicy & (1 <<EfiBootServicesData))
> >!= 0
> >
> > PcdImageProtectionPolicy == 0 &&
> > (PcdDxeNxMemoryProtectionPolicy & (1 <<
> >EfiRuntimeServicesData)) != 0
> >
> > PcdImageProtectionPolicy == 0 &&
> > (PcdDxeNxMemoryProtectionPolicy & (1 <<EfiBootServicesData))
> >!= 0
> >
> > PcdImageProtectionPolicy == 0 &&
> > (PcdDxeNxMemoryProtectionPolicy & (1 <<EfiLoaderData)) != 0
> >
> > In other words, PcdSetNxForStack and PcdImageProtectionPolicy have
> > priority over PcdDxeNxMemoryProtectionPolicy.
> >
> > Cc: Star Zeng <star.zeng@intel.com>
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Ruiyu Ni <ruiyu.ni@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>
> > ---
> > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 2 +
> > MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 4 +-
> > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 55 +++++++++++++
> ++++++++++-
> > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 33 +++++++++++++
> +
> > 4 files changed, 91 insertions(+), 3 deletions(-)
> >
> > diff --
> git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> b/MdeModulePkg/Core/DxeIp lPeim/DxeIpl.inf
> > index fd82657404..068e700074 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > @@ -117,6 +117,8 @@
> >
> > [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
> > gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack ##
> >SOMETIM
> ES_CONSUMES
> > + gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ##
> SOMETIMES_CONSUMES
> > + gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy ##
> >SOME
> TIMES_CONSUMES
> >
> > [Depex]
> > gEfiPeiLoadFilePpiGuid AND gEfiPeiMasterBootModePpiGuid
> > diff --
> git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c b/MdeModulePkg/
> Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > index d28baa3615..9a97205ef8 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > @@ -245,7 +245,7 @@ ToBuildPageTable (
> > return TRUE;
> > }
> >
> > - if (PcdGetBool (PcdSetNxForStack) && IsExecuteDisableBitAvailable
> >()) {
> > + if (ToEnableExecuteDisableFeature ()) {
> > return TRUE;
> > }
> >
> > @@ -436,7 +436,7 @@ HandOffToDxeCore (
> > BuildPageTablesIa32Pae = ToBuildPageTable ();
> > if (BuildPageTablesIa32Pae) {
> > PageTables = Create4GPageTablesIa32Pae (BaseOfStack,
> >STACK_SIZE);
> > - if (IsExecuteDisableBitAvailable ()) {
> > + if (ToEnableExecuteDisableFeature ()) {
> > EnableExecuteDisableBit();
> > }
> > }
> > diff --
> git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg
> /Core/DxeIplPeim/X64/VirtualMemory.c
> > index 496e219913..253fe84223 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > @@ -106,6 +106,56 @@ IsNullDetectionEnabled (
> > return ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) !=
> >0);
> > }
> >
> > +/**
> > + Check if Execute Disable Bit (IA32_EFER.NXE) should be enabled or not.
> > +
> > + @retval TRUE IA32_EFER.NXE should be enabled.
> > + @retval FALSE IA32_EFER.NXE should not be enabled.
> > +
> > +**/
> > +BOOLEAN
> > +ToEnableExecuteDisableFeature (
> > + VOID
> > + )
>
> I think we're over-complicating the name of this function. First, "To"
> looks unnecessary. Second, "Enable Execute Disable" is just an
> engineer's way to say "Disable Execution". Can we say right that:
> DisableExec()?
>
> Or at least, if we consider "NX" a word in its own right, "EnableNX()"?
I prefer more general one. Let's use DisableExec().
>
> > +{
> > + if (!IsExecuteDisableBitAvailable ()) {
> > + return FALSE;
> > + }
> > +
> > + //
> > + // Normally stack is type of EfiBootServicesData. Disabling NX
> >for stack
> > + // but enabling NX for EfiBootServicesData doesn't make any sense.
> > + //
>
> This comment is good.
>
> > + if (PcdGetBool (PcdSetNxForStack) == FALSE &&
>
> Please don't compare PcdGetBool() against TRUE or FALSE, just say
> PcdGetBool(), or !PcdGetBool().
>
> > + (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> >STACK_MEMORY_TYPE)
> != 0) {
> > + DEBUG ((DEBUG_ERROR,
> > + "ERROR: NX for stack is disabled but NX for its memory
> >type is enabled
> !\r\n"));
> > + ASSERT(!(PcdGetBool (PcdSetNxForStack) == FALSE &&
> > + (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> >STACK_MEMORY_T
> YPE) != 0));
> > + }
>
> Please drop both the explicit "if", and the DEBUG message. Just keep
> the comment (which is already fine) and the ASSERT(). The ASSERT()
> will tell people where to look, and the comment will explain the
> assertion. Also, in a RELEASE build, the check should be eliminated
> entirely, but that might not work for the explicit "if" (dependent on
> compilers and/or fixed vs. dynamic PCDs).
>
> Furthermore, keeping the logical negation operator as the outermost
> operator makes the code a lot harder to read. It's much better to just
> assert what we actually require, which is:
>
> (DxeNxMemoryProtectionPolicy covers BSD) --> SetNxForStack
>
> put differently,
>
> NOT(DxeNxMemoryProtectionPolicy covers BSD) OR SetNxForStack
>
> in C:
>
> ASSERT (
> (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & STACK_MEMORY_TYPE) ==
> 0 ||
> PcdGetBool (PcdSetNxForStack)
> );
>
I don't have strong opinions on these. So let's do it your way.
> > +
> > + //
> > + // Image data section could be type of EfiLoaderData,
> >EfiBootServicesData
> > + // or EfiRuntimeServicesData. Disabling NX for image data but
> >enabling NX
> > + // for any those memory types doesn't make any sense.
> > + //
>
> The comment is good, I just suggest extending it with the origin of
> the
> image: "Disabling NX for image data (regardless of image origin) for
> any those memory types ...".
>
Sure. I'll add it.
> > + if (PcdGet32 (PcdImageProtectionPolicy) == 0 &&
> > + (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & IMAGE_DATA_MEMOR
> Y_TYPE) != 0) {
> > + DEBUG ((DEBUG_ERROR,
> > + "ERROR: NX for image data is disabled but NX for its
> >memory type(s) is
> enabled!\r\n"));
> > + ASSERT (!(PcdGet32 (PcdImageProtectionPolicy) == 0 &&
> > + (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> >IMAGE_DATA_ME
> MORY_TYPE) != 0));
> > + }
>
> Summarizing my points from before, here we should have:
>
> ASSERT (
> (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & IMAGE_DATA_MEMORY_TY
> PE) == 0 ||
> PcdGet32 (PcdImageProtectionPolicy) == 3
> );
>
> That is,
>
> - If we disable DxeNxMemoryProtectionPolicy for all of EfiLoaderData,
> EfiBootServicesData, and EfiRuntimeServicesData, then any
> ImageProtectionPolicy is fine.
>
> - If we enable DxeNxMemoryProtectionPolicy for any of EfiLoaderData,
> EfiBootServicesData, and EfiRuntimeServicesData, then we require the
> platform to set ImageProtectionPolicy regardless of image origin.
>
> Thanks
> Laszlo
>
Good catch. I missed that part. Thanks.
> > +
> > + //
> > + // XD flag (BIT63) in page table entry is only valid if IA32_EFER.NXE is set.
> > + // Features controlled by Following PCDs need this feature to be enabled.
> > + //
> > + return (PcdGetBool (PcdSetNxForStack) ||
> > + PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0 ||
> > + PcdGet32 (PcdImageProtectionPolicy) != 0);
> > +}
> > +
> > /**
> > Enable Execute Disable Bit.
> >
> > @@ -755,7 +805,10 @@ CreateIdentityMappingPageTables (
> > //
> > EnablePageTableProtection ((UINTN)PageMap, TRUE);
> >
> > - if (PcdGetBool (PcdSetNxForStack)) {
> > + //
> > + // Set IA32_EFER.NXE if necessary.
> > + //
> > + if (ToEnableExecuteDisableFeature ()) {
> > EnableExecuteDisableBit ();
> > }
> >
> > diff --
> git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h b/MdeModulePkg
> /Core/DxeIplPeim/X64/VirtualMemory.h
> > index 85457ff937..9f152e6531 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> > @@ -179,6 +179,39 @@ typedef struct {
> > UINTN FreePages;
> > } PAGE_TABLE_POOL;
> >
> > +//
> > +// Bit field repsentations of some EFI_MEMORY_TYPE, for page table
> >initializ
> ation.
> > +//
> > +#define STACK_MEMORY_TYPE (1 << EfiBootServicesData)
> >/* 0x10 */
> > +#define IMAGE_DATA_MEMORY_TYPE ((1 << EfiLoaderData) |
> >/* 0x04
> */\
> > + (1 << EfiBootServicesData) |
> >/* 0x10 */\
> > + (1 <<
> >EfiRuntimeServicesData)/* 0x40 */\
> > + )
> >/* 0x54 */
> > +
> > +/**
> > + Check if Execute Disable Bit (IA32_EFER.NXE) should be enabled or not.
> > +
> > + @retval TRUE IA32_EFER.NXE should be enabled.
> > + @retval FALSE IA32_EFER.NXE should not be enabled.
> > +
> > +**/
> > +BOOLEAN
> > +ToEnableExecuteDisableFeature (
> > + VOID
> > + );
> > +
> > +/**
> > + The function will check if Execute Disable Bit is available.
> > +
> > + @retval TRUE Execute Disable Bit is available.
> > + @retval FALSE Execute Disable Bit is not available.
> > +
> > +**/
> > +BOOLEAN
> > +IsExecuteDisableBitAvailable (
> > + VOID
> > + );
> > +
> > /**
> > Enable Execute Disable Bit.
> >
> >
next prev parent reply other threads:[~2018-09-17 5:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 5:13 [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs Jian J Wang
2018-09-14 5:46 ` Wang, Jian J
2018-09-14 6:04 ` Ard Biesheuvel
2018-09-14 6:50 ` Wang, Jian J
2018-09-14 9:27 ` Laszlo Ersek
2018-09-17 1:00 ` Wang, Jian J
2018-09-14 9:50 ` Laszlo Ersek
2018-09-17 2:11 ` Wang, Jian J
2018-09-17 5:57 ` Zeng, Star [this message]
2018-09-17 10:13 ` Laszlo Ersek
2018-09-18 1:21 ` Wang, Jian J
2018-09-18 8:46 ` Zeng, Star
2018-09-19 9:13 ` Wang, Jian J
2018-09-19 11:39 ` Laszlo Ersek
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=0C09AFA07DD0434D9E2A0C6AEB0483103BBBA7A4@shsmsx102.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