StandaloneMmPkg/Core/StandaloneMmCore.inf | 5 +++++ StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 3 +++ StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h | 2 ++ MdePkg/Library/BasePrintLib/PrintLibInternal.c | 2 +- StandaloneMmPkg/Core/Dispatcher.c | 2 +- StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c | 11 +++++++--- StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c | 22 ++++++++++++++++++++ 7 files changed, 42 insertions(+), 5 deletions(-)
It is not always possible to deploy the standalone MM core in a way where
the runtime address is known at build time. This does not matter for most
modules, since they are relocated at dispatch time. However, for the MM
core itself, it means we need to do some extra work to relocate the image
in place if it ends up at a different offset than expected.
On AARCH64, the standalone MM stack is deployed inside a non-privileged
secure world container which only has limited control over its memory
mappings, and so we need to ensure that the executable code itself is
free of absolute quantities that need to be fixed up. This is very similar
to how shared libraries are constructed, given that pages can only be
shared between processes if they are not modified, even by the dynamic
loader. So we can use this support to emit the standaline MM core in a
way that guarantees that the executable code does not need to modify
itself (patch #4)
Patch #5 adds the actual code to perform the self relocation after the
.data section has been made writable and non-executable. Note that the
PE/COFF library code modifies the header in place, and so in the case
where we need to perform the runtime relocation, we need to remap the
header page writable and non-executable as well.
The remaining patches are optimizations and fixes I picked up along
the way.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ard Biesheuvel (5):
MdePkg/BasePrintLib: avoid absolute addresses for error strings
StandaloneMmPkg/Core: fix bogus FV pointer in DEBUG string
StandaloneMmPkg/Core: add missing GUID reference
StandaloneMmPkg: generate position independent code for StMM core
StandaloneMmPkg/StandaloneMmCoreEntryPoint: relocate StMM core on the
fly
StandaloneMmPkg/Core/StandaloneMmCore.inf | 5 +++++
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 3 +++
StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h | 2 ++
MdePkg/Library/BasePrintLib/PrintLibInternal.c | 2 +-
StandaloneMmPkg/Core/Dispatcher.c | 2 +-
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c | 11 +++++++---
StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c | 22 ++++++++++++++++++++
7 files changed, 42 insertions(+), 5 deletions(-)
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#61038): https://edk2.groups.io/g/devel/message/61038
Mute This Topic: https://groups.io/mt/74792287/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Hi Ard, Tested on QEMU with the op-tee patches i mentioned in my RFC [1] Everything seems to work correctly [1] https://edk2.groups.io/g/devel/message/60835 On Wed, Jun 10, 2020 at 10:17:35AM +0200, Ard Biesheuvel wrote: > It is not always possible to deploy the standalone MM core in a way where > the runtime address is known at build time. This does not matter for most > modules, since they are relocated at dispatch time. However, for the MM > core itself, it means we need to do some extra work to relocate the image > in place if it ends up at a different offset than expected. > > On AARCH64, the standalone MM stack is deployed inside a non-privileged > secure world container which only has limited control over its memory > mappings, and so we need to ensure that the executable code itself is > free of absolute quantities that need to be fixed up. This is very similar > to how shared libraries are constructed, given that pages can only be > shared between processes if they are not modified, even by the dynamic > loader. So we can use this support to emit the standaline MM core in a > way that guarantees that the executable code does not need to modify > itself (patch #4) > > Patch #5 adds the actual code to perform the self relocation after the > .data section has been made writable and non-executable. Note that the > PE/COFF library code modifies the header in place, and so in the case > where we need to perform the runtime relocation, we need to remap the > header page writable and non-executable as well. > > The remaining patches are optimizations and fixes I picked up along > the way. > > Cc: Michael D Kinney <michael.d.kinney@intel.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Sami Mujawar <sami.mujawar@arm.com> > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Ard Biesheuvel (5): > MdePkg/BasePrintLib: avoid absolute addresses for error strings > StandaloneMmPkg/Core: fix bogus FV pointer in DEBUG string > StandaloneMmPkg/Core: add missing GUID reference > StandaloneMmPkg: generate position independent code for StMM core > StandaloneMmPkg/StandaloneMmCoreEntryPoint: relocate StMM core on the > fly > > StandaloneMmPkg/Core/StandaloneMmCore.inf | 5 +++++ > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCoreEntryPoint.inf | 3 +++ > StandaloneMmPkg/Include/Library/AArch64/StandaloneMmCoreEntryPoint.h | 2 ++ > MdePkg/Library/BasePrintLib/PrintLibInternal.c | 2 +- > StandaloneMmPkg/Core/Dispatcher.c | 2 +- > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c | 11 +++++++--- > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c | 22 ++++++++++++++++++++ > 7 files changed, 42 insertions(+), 5 deletions(-) > > -- > 2.26.2 > Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#61068): https://edk2.groups.io/g/devel/message/61068 Mute This Topic: https://groups.io/mt/74792287/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 6/10/20 10:17 AM, Ard Biesheuvel wrote: > It is not always possible to deploy the standalone MM core in a way where > the runtime address is known at build time. This does not matter for most > modules, since they are relocated at dispatch time. However, for the MM > core itself, it means we need to do some extra work to relocate the image > in place if it ends up at a different offset than expected. > > On AARCH64, the standalone MM stack is deployed inside a non-privileged > secure world container which only has limited control over its memory > mappings, and so we need to ensure that the executable code itself is > free of absolute quantities that need to be fixed up. This is very similar > to how shared libraries are constructed, given that pages can only be > shared between processes if they are not modified, even by the dynamic > loader. So we can use this support to emit the standaline MM core in a > way that guarantees that the executable code does not need to modify > itself (patch #4) > > Patch #5 adds the actual code to perform the self relocation after the > .data section has been made writable and non-executable. Note that the > PE/COFF library code modifies the header in place, and so in the case > where we need to perform the runtime relocation, we need to remap the > header page writable and non-executable as well. > > The remaining patches are optimizations and fixes I picked up along > the way. > > Cc: Michael D Kinney <michael.d.kinney@intel.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Sami Mujawar <sami.mujawar@arm.com> > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Ard Biesheuvel (5): > MdePkg/BasePrintLib: avoid absolute addresses for error strings > StandaloneMmPkg/Core: fix bogus FV pointer in DEBUG string > StandaloneMmPkg/Core: add missing GUID reference > StandaloneMmPkg: generate position independent code for StMM core > StandaloneMmPkg/StandaloneMmCoreEntryPoint: relocate StMM core on the > fly > Patches 2-5 merged as #702 (patch #1 was respun separately, and merged as #699 earlier) Thanks all -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#61342): https://edk2.groups.io/g/devel/message/61342 Mute This Topic: https://groups.io/mt/74792287/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 6/10/20 10:17 AM, Ard Biesheuvel wrote: > It is not always possible to deploy the standalone MM core in a way where > the runtime address is known at build time. This does not matter for most > modules, since they are relocated at dispatch time. However, for the MM > core itself, it means we need to do some extra work to relocate the image > in place if it ends up at a different offset than expected. > > On AARCH64, the standalone MM stack is deployed inside a non-privileged > secure world container which only has limited control over its memory > mappings, and so we need to ensure that the executable code itself is > free of absolute quantities that need to be fixed up. This is very similar > to how shared libraries are constructed, given that pages can only be > shared between processes if they are not modified, even by the dynamic > loader. So we can use this support to emit the standaline MM core in a > way that guarantees that the executable code does not need to modify > itself (patch #4) > > Patch #5 adds the actual code to perform the self relocation after the > .data section has been made writable and non-executable. Note that the > PE/COFF library code modifies the header in place, and so in the case > where we need to perform the runtime relocation, we need to remap the > header page writable and non-executable as well. > > The remaining patches are optimizations and fixes I picked up along > the way. > > Cc: Michael D Kinney <michael.d.kinney@intel.com> > Cc: Liming Gao <liming.gao@intel.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Sami Mujawar <sami.mujawar@arm.com> > Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> > Any thoughts from the StandaloneMmPkg co-maintainers? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#61209): https://edk2.groups.io/g/devel/message/61209 Mute This Topic: https://groups.io/mt/74792287/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.