From: Leif Lindholm <leif.lindholm@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"afish@apple.com" <afish@apple.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"Tian, Feng" <feng.tian@intel.com>,
"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [PATCH v4 1/7] ArmPkg/CpuDxe: ignore attribute changes during SyncCacheConfig()
Date: Mon, 27 Feb 2017 15:41:45 +0000 [thread overview]
Message-ID: <20170227154145.GF16034@bivouac.eciton.net> (raw)
In-Reply-To: <CAKv+Gu_rdArFftjhfvPZbyjzpWYeNDTvOo5t6euz=BEWBkgT3Q@mail.gmail.com>
On Mon, Feb 27, 2017 at 03:39:54PM +0000, Ard Biesheuvel wrote:
> On 27 February 2017 at 15:38, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > On Mon, Feb 27, 2017 at 03:33:56PM +0000, Ard Biesheuvel wrote:
> >> On 27 February 2017 at 15:32, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> >> > On Mon, Feb 27, 2017 at 02:38:05PM +0000, Ard Biesheuvel wrote:
> >> >> To prevent the initial MMU->GCD memory space map synchronization from
> >> >> stripping permissions attributes [which we cannot use in the GCD memory
> >> >> space map, unfortunately], implement the same approach as x86, and ignore
> >> >> SetMemoryAttributes() calls during the time SyncCacheConfig() is in
> >> >> progress. This is a horrible hack, but is currently the only way we can
> >> >> implement strict permissions on arbitrary memory regions [as opposed to
> >> >> PE/COFF text/data sections only]
> >> >
> >> > Sounds like another excellent argument for why this CpuDxe should be
> >> > cosying up with the UefiCpuPkg one longer-term.
> >> >
> >>
> >> I suppose so, yes.
> >>
> >> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> >> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
> >> >> ---
> >> >> ArmPkg/Drivers/CpuDxe/CpuDxe.c | 3 +++
> >> >> ArmPkg/Drivers/CpuDxe/CpuDxe.h | 1 +
> >> >> ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c | 4 ++++
> >> >> 3 files changed, 8 insertions(+)
> >> >>
> >> >> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.c b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >> >> index 5aa5b874144a..1955d1dece03 100644
> >> >> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >> >> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.c
> >> >> @@ -17,6 +17,7 @@
> >> >>
> >> >> #include <Guid/IdleLoopEvent.h>
> >> >>
> >> >> +BOOLEAN gIsFlushingGCD;
> >> >
> >> > OK, I am unable to not bikeshed this:
> >> > The behaviour you're copying is implemented via a variable called
> >> > mIsFlushingGCD. Why change the prefix? Surely we're not looking to
> >> > export this variable any further in ARM?
> >> >
> >>
> >> Because it is not local the one compilation unit, that's all. It is
> >> not in a library, so in that sense, it is guaranteed to remain local
> >> to this module, if that is any consolation.
> >
> > Ah, excellent.
> >
> > So, from how I read the coding standards (section 4.4), 'm' would
> > still be the appropriate prefix:
> > "A module variable is intended to only be accessed across a small set of
> > related routines that have strict rules for accessing the data; in
> > effect, constrained to the set of files described within a single .inf
> > file."
> >
>
> Ah, nice, I wasn't aware of that. I will use the m prefix instead, then.
In that case,
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> Thanks,
> Ard.
>
>
> >> >>
> >> >> /**
> >> >> This function flushes the range of addresses from Start to Start+Length
> >> >> @@ -261,7 +262,9 @@ CpuDxeInitialize (
> >> >> // and that calls EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes, so this code needs to go
> >> >> // after the protocol is installed
> >> >> //
> >> >> + gIsFlushingGCD = TRUE;
> >> >> SyncCacheConfig (&mCpu);
> >> >> + gIsFlushingGCD = FALSE;
> >> >>
> >> >> // If the platform is a MPCore system then install the Configuration Table describing the
> >> >> // secondary core states
> >> >> diff --git a/ArmPkg/Drivers/CpuDxe/CpuDxe.h b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> >> >> index a00fc3064362..085e4cab2921 100644
> >> >> --- a/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> >> >> +++ b/ArmPkg/Drivers/CpuDxe/CpuDxe.h
> >> >> @@ -37,6 +37,7 @@
> >> >> #include <Protocol/DebugSupportPeriodicCallback.h>
> >> >> #include <Protocol/LoadedImage.h>
> >> >>
> >> >> +extern BOOLEAN gIsFlushingGCD;
> >> >
> >> > Eew ... this suggest we are.
> >> >
> >> > /
> >> > Leif
> >> >
> >> >>
> >> >> /**
> >> >> This function registers and enables the handler specified by InterruptHandler for a processor
> >> >> diff --git a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> >> >> index ebe593d1c325..6dfec7e55888 100644
> >> >> --- a/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> >> >> +++ b/ArmPkg/Drivers/CpuDxe/CpuMmuCommon.c
> >> >> @@ -188,6 +188,10 @@ CpuSetMemoryAttributes (
> >> >> UINTN RegionLength;
> >> >> UINTN RegionArmAttributes;
> >> >>
> >> >> + if (gIsFlushingGCD) {
> >> >> + return EFI_SUCCESS;
> >> >> + }
> >> >> +
> >> >> if ((BaseAddress & (SIZE_4KB - 1)) != 0) {
> >> >> // Minimum granularity is SIZE_4KB (4KB on ARM)
> >> >> DEBUG ((EFI_D_PAGE, "CpuSetMemoryAttributes(%lx, %lx, %lx): Minimum ganularity is SIZE_4KB\n", BaseAddress, Length, EfiAttributes));
> >> >> --
> >> >> 2.7.4
> >> >>
next prev parent reply other threads:[~2017-02-27 15:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 14:38 [PATCH v4 0/7] MdeModulePkg/DxeCore: increased memory protection Ard Biesheuvel
2017-02-27 14:38 ` [PATCH v4 1/7] ArmPkg/CpuDxe: ignore attribute changes during SyncCacheConfig() Ard Biesheuvel
2017-02-27 15:32 ` Leif Lindholm
2017-02-27 15:33 ` Ard Biesheuvel
2017-02-27 15:38 ` Leif Lindholm
2017-02-27 15:39 ` Ard Biesheuvel
2017-02-27 15:41 ` Leif Lindholm [this message]
2017-02-27 14:38 ` [PATCH v4 2/7] MdeModulePkg/PeiCore: allocate BootServicesCode memory for PE/COFF images Ard Biesheuvel
2017-02-28 5:42 ` Gao, Liming
2017-02-27 14:38 ` [PATCH v4 3/7] MdeModulePkg/EbcDxe: use EfiBootServicesCode memory for thunks Ard Biesheuvel
2017-02-27 14:38 ` [PATCH v4 4/7] MdeModulePkg/DxeCore: use separate lock for pool allocations Ard Biesheuvel
2017-02-28 9:32 ` Gao, Liming
2017-02-27 14:38 ` [PATCH v4 5/7] MdeModulePkg: define PCD for DXE memory protection policy Ard Biesheuvel
2017-02-27 14:38 ` [PATCH v4 6/7] MdeModulePkg/DxeCore: implement " Ard Biesheuvel
2017-02-28 9:33 ` Gao, Liming
2017-02-27 14:38 ` [PATCH v4 7/7] ArmVirtPkg/ArmVirt.dsc.inc: enable NX memory protection for all platforms Ard Biesheuvel
2017-02-28 5:48 ` [PATCH v4 0/7] MdeModulePkg/DxeCore: increased memory protection Yao, Jiewen
2017-02-28 14:59 ` Ard Biesheuvel
2017-02-28 10:46 ` Laszlo Ersek
2017-02-28 10:52 ` Ard Biesheuvel
2017-02-28 10:59 ` Ard Biesheuvel
2017-02-28 11:47 ` Ard Biesheuvel
2017-02-28 23:46 ` Laszlo Ersek
2017-03-13 8:43 ` Michael Zimmermann
2017-03-13 8:50 ` Ard Biesheuvel
2017-03-13 8:53 ` Michael Zimmermann
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=20170227154145.GF16034@bivouac.eciton.net \
--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