From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.1259.1591813987757010077 for ; Wed, 10 Jun 2020 11:33:07 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5352C1FB; Wed, 10 Jun 2020 11:33:07 -0700 (PDT) Received: from [192.168.1.69] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 19F1B3F66F; Wed, 10 Jun 2020 11:33:05 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH 4/5] StandaloneMmPkg: generate position independent code for StMM core To: Sean Brogan , devel@edk2.groups.io Cc: Michael D Kinney , Liming Gao , Jiewen Yao , Sami Mujawar , Ilias Apalodimas References: <20200610081740.54581-1-ard.biesheuvel@arm.com> <20200610081740.54581-5-ard.biesheuvel@arm.com> From: "Ard Biesheuvel" Message-ID: <2176cedb-1500-751f-fb5b-eb39718390bc@arm.com> Date: Wed, 10 Jun 2020 20:33:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/10/20 8:21 PM, Sean Brogan wrote: > Ard, >=20 > I see you are only doing this for GCC? >=20 > Is it not needed for VS or clang? Are these toolchains not supported fo= r=20 > StandaloneMmPkg? >=20 This works with Clang as well as GCC (Clang is part of the GCC toolchain=20 family in EDK2) None of the AArch64 platforms we have in EDK2 or edk2-platforms can be=20 built with VS today: the problem is that the asm dialect is different,=20 and we don't have .asm versions of the startup code that can be built=20 with VS. I think some of the common pieces have been ported by Pete=20 Batard (so you can build individual drivers for AArch64 using VS), but=20 nothing else. > Not trying to hold up your work and don't expect you to enable every=20 > toolchain but also don't like the idea of only building out support for= =20 > a single toolchain given all the work that has gone into making modules= =20 > compatible with numerous toolchains. >=20 > thoughts? >=20 Leif and I tasked someone with adding this VS support when we were both=20 at Linaro, but this never materialized, unfortunately. I don't have a=20 Windows machine, and no bandwidth to educate myself on the use of Visual=20 Studio (last version I used was 6 :-)), so I am going to leave this up=20 to someone else. That said, this alternative approach (suggested by Jiewen) was adopted=20 to rely less on ELF particulars or GCC/binutils. I do think that=20 building this code needs the attention of someone who understanfds the=20 VS toolchain really well, though, since we need to build a standalone=20 PE/COFF executable that is structured as a shared library (i.e., with no=20 relocation records pointing into the executable segment), otherwise=20 there is no way we can dispatch those running at S-EL0 under the Secure=20 Partition Manager. Do you have any candidates that could help me figure out the build=20 options we need for VS here? Beyond that, I don't see any GCC=20 dependencies in StandaloneMmPkg at all. >=20 > 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 >> --- >> =20 >> StandaloneMmPkg/Core/StandaloneMmCore.inf = =20 >> | 4 ++++ >> =20 >> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEnt= ryPoint.inf=20 >> | 3 +++ >> =C2=A0 2 files changed, 7 insertions(+) >> >> diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf=20 >> b/StandaloneMmPkg/Core/StandaloneMmCore.inf >> index d17ff9965bdc..87bf6e9440a7 100644 >> --- a/StandaloneMmPkg/Core/StandaloneMmCore.inf >> +++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf >> @@ -75,3 +75,7 @@ [Guids] >> =C2=A0=C2=A0=C2=A0 gEfiEventLegacyBootGuid >> >> =C2=A0=C2=A0=C2=A0 gEfiEventExitBootServicesGuid >> >> =C2=A0=C2=A0=C2=A0 gEfiEventReadyToBootGuid >> >> + >> >> +[BuildOptions] >> >> +=C2=A0 GCC:*_*_*_CC_FLAGS =3D -fpie >> >> +=C2=A0 GCC:*_*_*_DLINK_FLAGS =3D -Wl,-z,text,-Bsymbolic,-pie >> >> diff --git=20 >> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreE= ntryPoint.inf=20 >> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreE= ntryPoint.inf=20 >> >> index 891c292e92f8..7d6ee4e08ecb 100644 >> ---=20 >> a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreE= ntryPoint.inf=20 >> >> +++=20 >> b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreE= ntryPoint.inf=20 >> >> @@ -48,3 +48,6 @@ [Guids] >> =C2=A0=C2=A0=C2=A0 gEfiMmPeiMmramMemoryReserveGuid >> >> =C2=A0=C2=A0=C2=A0 gEfiStandaloneMmNonSecureBufferGuid >> >> =C2=A0=C2=A0=C2=A0 gEfiArmTfCpuDriverEpDescriptorGuid >> >> + >> >> +[BuildOptions] >> >> +=C2=A0 GCC:*_*_*_CC_FLAGS =3D -fpie >>