public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Sean" <spbrogan@outlook.com>
To: devel@edk2.groups.io, ard.biesheuvel@arm.com
Cc: Michael D Kinney <michael.d.kinney@intel.com>,
	Liming Gao <liming.gao@intel.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [edk2-devel] [PATCH 4/5] StandaloneMmPkg: generate position independent code for StMM core
Date: Wed, 10 Jun 2020 11:21:09 -0700	[thread overview]
Message-ID: <BN8PR07MB6962CDE94E9BD49527C6B0D9C8830@BN8PR07MB6962.namprd07.prod.outlook.com> (raw)
In-Reply-To: <20200610081740.54581-5-ard.biesheuvel@arm.com>

Ard,

I see you are only doing this for GCC?

Is it not needed for VS or clang? Are these toolchains not supported for 
StandaloneMmPkg?

Not trying to hold up your work and don't expect you to enable every 
toolchain but also don't like the idea of only building out support for 
a single toolchain given all the work that has gone into making modules 
compatible with numerous toolchains.

thoughts?

Thanks
Sean



On 6/10/2020 1:17 AM, Ard Biesheuvel wrote:
> The standalone MM core runs in a restricted environment that is set
> up by a higher privilege level, and which may not allow memory regions
> to be writable and executable at the same time.
> 
> This means that making the StMM core self-relocatable requires that
> all the targets of the relocation fixups are outside of the executable
> region of the image, given that we cannot remap the executable code
> writable from the executable code itself without losing those execute
> permissions.
> 
> So instead, use the existing toolchain support to ensure that position
> independent code is used where possible, and that all the remaining
> relocated quantities are emitted into the data section. (Note that
> staticallly initialized const pointers will be emitted into the
> .data.rel.ro section, which gets pulled into the .data section by
> our linker script)
> 
> To ensure that we don't pick up any absolute references in executable
> code inadvertently (e.g., in assembler code), add the '-z text' linker
> option which will force the build to fail in this case.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
> ---
>   StandaloneMmPkg/Core/StandaloneMmCore.inf                                         | 4 ++++
>   StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 3 +++
>   2 files changed, 7 insertions(+)
> 
> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> index d17ff9965bdc..87bf6e9440a7 100644
> --- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
> @@ -75,3 +75,7 @@ [Guids]
>     gEfiEventLegacyBootGuid
> 
>     gEfiEventExitBootServicesGuid
> 
>     gEfiEventReadyToBootGuid
> 
> +
> 
> +[BuildOptions]
> 
> +  GCC:*_*_*_CC_FLAGS = -fpie
> 
> +  GCC:*_*_*_DLINK_FLAGS = -Wl,-z,text,-Bsymbolic,-pie
> 
> diff --git a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
> index 891c292e92f8..7d6ee4e08ecb 100644
> --- a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
> +++ b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf
> @@ -48,3 +48,6 @@ [Guids]
>     gEfiMmPeiMmramMemoryReserveGuid
> 
>     gEfiStandaloneMmNonSecureBufferGuid
> 
>     gEfiArmTfCpuDriverEpDescriptorGuid
> 
> +
> 
> +[BuildOptions]
> 
> +  GCC:*_*_*_CC_FLAGS = -fpie
> 

  reply	other threads:[~2020-06-10 18:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10  8:17 [PATCH 0/5] StandaloneMmPkg: make StMM core relocatable Ard Biesheuvel
2020-06-10  8:17 ` [PATCH 1/5] MdePkg/BasePrintLib: avoid absolute addresses for error strings Ard Biesheuvel
2020-06-10  8:37   ` Ard Biesheuvel
2020-06-10 15:09     ` [edk2-devel] " Michael D Kinney
2020-06-10 16:39       ` Ard Biesheuvel
2020-06-10  8:17 ` [PATCH 2/5] StandaloneMmPkg/Core: fix bogus FV pointer in DEBUG string Ard Biesheuvel
2020-06-14 12:35   ` [edk2-devel] " Yao, Jiewen
2020-06-15 12:42     ` Sami Mujawar
2020-06-10  8:17 ` [PATCH 3/5] StandaloneMmPkg/Core: add missing GUID reference Ard Biesheuvel
2020-06-14 12:36   ` Yao, Jiewen
2020-06-15 12:49     ` [edk2-devel] " Sami Mujawar
2020-06-10  8:17 ` [PATCH 4/5] StandaloneMmPkg: generate position independent code for StMM core Ard Biesheuvel
2020-06-10 18:21   ` Sean [this message]
2020-06-10 18:33     ` [edk2-devel] " Ard Biesheuvel
2020-06-14 12:38   ` Yao, Jiewen
2020-06-10  8:17 ` [PATCH 5/5] StandaloneMmPkg/StandaloneMmCoreEntryPoint: relocate StMM core on the fly Ard Biesheuvel
2020-06-14 12:37   ` [edk2-devel] " Yao, Jiewen
2020-06-15 13:59   ` Sami Mujawar
2020-06-15 14:12     ` Ard Biesheuvel
2020-06-15 14:40       ` Sami Mujawar
2020-06-10 10:21 ` [PATCH 0/5] StandaloneMmPkg: make StMM core relocatable Ilias Apalodimas
2020-06-12  9:58 ` Ard Biesheuvel
2020-06-16 16:16 ` Ard Biesheuvel

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=BN8PR07MB6962CDE94E9BD49527C6B0D9C8830@BN8PR07MB6962.namprd07.prod.outlook.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