| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apply PE/COFF fixups when starting up the standalone MM core, so that
it can execute at any address regardless of the link time address.
Note that this requires the PE/COFF image to be emitted with its
relocation section preserved. Special care is taken to ensure that
TE images are dealt with correctly as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.tianocore.org/show_bug.cgi?id=1373
Replace BSD 2-Clause License with BSD+Patent License. This change is
based on the following emails:
https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
RFCs with detailed process for the license change:
V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a simple CPU driver that exports the
EFI_MM_CONFIGURATION_PROTOCOL to allow registration of the Standalone
MM Foundation entry point. It preserves the existing notification
mechanism for the configuration protocol.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
Platforms and is initialised during the SEC phase. ARM Trusted firmware
in EL3 is responsible for initialising the architectural context for
S-EL0 and loading the Standalone MM image. The memory allocated to this
image is marked as RO+X. Heap memory is marked as RW+XN.
Certain actions have to be completed prior to executing the generic code
in the Standalone MM Core module. These are:
1. Memory permission attributes for each section of the Standalone MM
Core module need to be changed prior to accessing any RW data.
2. A Hob list has to be created with information that allows the MM
environment to initialise and dispatch drivers.
Furthermore, this module is responsible for handing over runtime MM
events to the Standalone MM CPU driver and returning control to ARM
Trusted Firmware upon event completion. Hence it needs to know the CPU
driver entry point.
This patch implements an entry point module that ARM Trusted Firmware
jumps to in S-EL0. It then performs the above actions before calling the
Standalone MM Foundation entry point and handling subsequent MM events.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Achin Gupta <achin.gupta@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch implements module entry point library for Standalone
management mode (MM) Drivers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
|
| |
|
|
|
|
|
|
|
|
| |
This patch implements management mode memory allocation services.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MM memory check library library implementation. This library consumes
MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
library instance, the platform should produce all MMRAM range via
MM_ACCESS_PROTOCOL, including the range for firmware (like MM Core
and MM driver) and/or specific dedicated hardware.
This patch provides services for MM Memory Operation.
The management mode Mem Library provides function for checking if buffer
is outside MMRAM and valid. It also provides functions for copy data
from MMRAM to non-MMRAM, from non-MMRAM to MMRAM,
from non-MMRAM to non-MMRAM, or set data in non-MMRAM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
|
|
|
This patch implements a firmware volume library that can be used by the
Standalone management mode core module to parse the firmware volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
|
