Ensure consistency across all Arm platforms, even those that may already
have an existing macro for this purpose.
Change-Id: I07cd4cfcacf2c991717f4c115cb0babd2c614d6f
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Datastore symbol used by EL3 SPMC is not relocated at
boot time when using ENABLE_PIE=1.
Use linker script markers instead of symbol.
Signed-off-by: Shruti Gupta <shruti.gupta@arm.com>
Change-Id: If22d2fc8deacc74c73d7dc51bb70093935d9fa2b
On FVP's the default SRAM size is severly restrictive. However, more
recent models support larger SRAM configurations (> 256 Kb). We
introduced the flag FVP_TRUSTED_SRAM_SIZE to allow for TF to handle
different configurations.
BL31 automatically benefits from this optimisation since it starts from
the bottom of shared memory, and runs up to the end of SRAM. Increase
the size of all BL2 builds in proportion to FVP_TRUSTED_SRAM_SIZE so
that BL2 covers around a third of SRAM.
Change-Id: Idf37e8cb86507ea44b97ac8b3b90fffefe13f57a
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
This setup helps to mimic an end-to-end RAS handling flow inspired
by real world design with a dedicated RAS secure partition managed
by SPMC.
The detailed steps are documented as comments in the relevant source
files introduced in this patch.
Change-Id: I97737c66649f6e49840fa0bdf2e0af4fb6b08fc7
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
* changes:
docs: mark PSA_CRYPTO as an experimental feature
feat(fvp): increase BL1 RW area for PSA_CRYPTO implementation
feat(mbedtls-psa): mbedTLS PSA Crypto with ECDSA
The firmware handoff framework is a light weight mechanism for sharing
information between bootloader stages. Add support for this framework at
the handoff boundary between runtime firmware BL31 and NS software on FVP.
Change-Id: Ib02e0e4c20a39e32e06da667caf2ce5a28de1e28
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
When using PSA Crypto API, few algorithms like ECDSA require a
larger BL1 RW area. Hence added an additional BL1 RW page when
PSA_CRYPTO is selected.
Change-Id: Id6994667641a0b1e36b6a356d7c39a125d62ac01
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
The XLAT and MMAP table entries are increased as a part of this
patch: 12fe591 , but this is causing failures for some builds,
so conditionally increased the XLAT and MMAP table entries
Change-Id: I31e8c811bebc767d7187e045a35c9db0eef13ae0
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
To make room for all image measurements using the
RME+SPM+TBB+MEASURED_BOOT test configuration, the Event Log's maximum
size has been significantly increased.
Change-Id: I0b9948dab893e14677bca0afa07167648a6c2729
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Maximum entries for MMAP and XLAT have been increased in order to
support the configuration SPM+RME, along with MEASURED_BOOT and
TRUSTED_BOARD_BOOT.
Change-Id: Ic0a0aefecb49d7ccc71357c4bd94e7bd2e5f57c4
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Adjusted BL2 maximum size as per total SRAM size.
Change-Id: Ic3b398574a17e8a784e7c4dbe3fe69d1fb2b5e16
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Adjusted BL31 maximum size as per total SRAM size.
Change-Id: Ifdfdedb8af3e001cebba8e60c973f3c72be11652
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
In some build configurations TF-A can exceed the existing 256KB SRAM,
triggering a build failure. More recent versions of the base FVP allow
you to configure a larger Trusted SRAM of 512KB.
This change introduces the `FVP_TRUSTED_SRAM_SIZE` build option, which
allows you to explicitly specify how much of the Trusted SRAM to
utilise, e.g.:
FVP_TRUSTED_SRAM_SIZE=384
This allows previously-failing configurations to build successfully by
utilising more than the originally-allocated 256KB of the Trusted SRAM
while maintaining compatibility with older configurations/models that
only require/have 256KB.
Change-Id: I8344d3718564cd2bd53f1e6860e2fe341ae240b0
Signed-off-by: Chris Kay <chris.kay@arm.com>
While doing RAS related tests there were few patches related with
fault injection and handling were applied through CI hooks.
These patches were invisible as they were applied and removed after the
build is done.
This patch introduces build macro PLATFORM_TEST_RAS_FFH and moves the
patches applied through CI under this.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Iddba52f3ebf21f575a473e50c607a944391156b9
PLAT_SP_PRI is used by SPM_MM and it is assigned same value as RAS
priority. Which is not allowed by exception handling framework and
causes build failure if both SPM_MM and RAS is enabled.
To fix this problem assign SP a different priority than RAS.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Iff64ac547f0966c0d94ac7c3ab0eb1e3151fb314
Reserved 4KB area for Event Log in DRAM1. This area is used by BL2
to copy Event Log from internal SRAM to this carved out DRAM region
in the subsequent patch.
Change-Id: I7b405775c66d249e31edf7688d95770e6c05c175
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
CRYPTO_SUPPORT is enabled by default when TRUSTED_BOARD_BOOT is
enabled so usage CRYPTO_SUPPORT in conjunction with TRUSTED_BOARD_BOOT
might sometime be confusing to look at.
Adding minor cleanup to make it look simpler with conditions.
No functionality changes.
Change-Id: I800524d54ea56dc27b6c6da26c75a07f5f6de984
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
To support mbedtls3.3 increase BL1_RW and BL2 size rsa+ecdsa alg.
Increase both by one page size. In mbedtls3.3 numerous config options
have been tweaked and made defaults[1] thus a small increase in size
can result for mbedtls-3.3
This size limitation is observed when we build TF-A with
TF_MBEDTLS_KEY_ALG=rsa+ecdsa this approach is used in juno as well,
so use similar approach for FVP.
[1]: https://github.com/Mbed-TLS/mbedtls/blob/development/docs/3.0-migration-guide.md
Change-Id: I8a423711ac50b3d615c1d9650086cdbca5051c8e
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Added platform hooks to retrieve DRTM features and
address map.
Additionally, implemented these hooks for the FVP platform.
Signed-off-by: John Powell <john.powell@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I5621cc9807ffff8139ae8876250147f7b2c76759
DRTM implementation maps the DLME data region provided by the
DCE-preamble in BL31, hence increased MAX_XLAT_TABLES entries
count.
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Signed-off-by: Lucian Paul-Trifu <lucian.paultrifu@gmail.com>
Change-Id: I5f0ac69e009c4f81d3590fdb1f4c0a7f73c5c99d
The stack size of BL31 has been increased to accommodate the
introduction of mbedTLS support for DRTM.
Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Signed-off-by: Lucian Paul-Trifu <lucian.paultrifu@gmail.com>
Change-Id: Id0beacf4df553af4ecbe714af20e71604ccfed59
Use the RMM shared buffer to attestation token and signing key SMCs.
Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: I313838b26d3d9334fb0fe8cd4b229a326440d2f4
This patch adds the infrastructure needed to pass boot arguments from
EL3 to RMM and allocates a shared buffer between both worlds that can
be used, among others, to pass a boot manifest to RMM. The buffer is
composed a single memory page be used by a later EL3 <-> RMM interface
by all CPUs.
The RMM boot manifest is not implemented by this patch.
In addition to that, this patch also enables support for RMM when
RESET_TO_BL31 is enabled.
Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: I855cd4758ee3843eadd9fb482d70a6d18954d82a
Increase the space for BL2 by 0xC000 to accommodate the increase in size
of BL2 when ARM_BL31_IN_DRAM is set.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ifc99da51f2de3c152bbed1c8269dcc8b9100797a
Introduce additional #defines for running with the EL3
SPMC on the FVP.
The increase in xlat tables has been chosen to allow
the test cases to complete successfully and may need
adjusting depending on the desired usecase.
Signed-off-by: Marc Bonnici <marc.bonnici@arm.com>
Change-Id: I7f44344ff8b74ae8907d53ebb652ff8def2d2562
This change performs a basic configuration of the SMMU root registers
interface on an RME enabled system. This permits enabling GPC checks
for transactions originated from a non-secure or secure device upstream
to an SMMU. It re-uses the boot time GPT base address and configuration
programmed on the PE.
The root register file offset is platform dependent and has to be
supplied on a model command line.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I4f889be6b7afc2afb4d1d147c5c1c3ea68f32e07
Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue since no software runs in non-secure world at this time
(non-secure world has not been started yet).
It does not provide a guarantee though since malicious external
NS-agents can take control of this memory region for update/corruption
after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat
is mapped to Threat ID#3 (Bypass authentication scenario) in threat
model [1].
Hence modified the code as below -
1. BL2 loads the HW_CONFIG into secure memory
2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an
address provided by the newly added property(ns-load-address) in
the 'hw-config' node of the FW_CONFIG
3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that
it can retrieve details (address and size) of HW_CONFIG from
FW_CONFIG
4. A secure and non-secure HW_CONFIG address will eventually be used
by BL31/SP_MIN/BL32 and BL33 components respectively
5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads
information from it to local variables (structures) and then
unmaps it
6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears
sufficient, and it will also create a free space for any future
components to be added to memory
[1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html
Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Add a dummy platform token to RMMD and return it on request. The
platform token is requested with an SMC with the following parameters:
* Fid (0xC40001B3).
* Platform token PA (the platform token is copied at this address by
the monitor). The challenge object needs to be passed by
the caller in this buffer.
* Platform token len.
* Challenge object len.
When calling the SMC, the platform token buffer received by EL3 contains
the challenge object. It is not used on the FVP and is only printed to
the log.
Signed-off-by: Mate Toth-Pal <mate.toth-pal@arm.com>
Signed-off-by: Subhasish Ghosh <subhasish.ghosh@arm.com>
Change-Id: I8b2f1d54426c04e76d7a3baa6b0fbc40b0116348
Currently only the lowest 2 DRAM region were configured in the
TrustZone Controller, but the platform supports 6 regions spanning the
whole address space.
Configuring all of them to allow tests to access memory also in those
higher memory regions.
FVP memory map:
https://developer.arm.com/documentation/100964/1116/Base-Platform/Base---memory/Base-Platform-memory-map
Note that last row is wrong, describing a non-existing 56bit address,
all region labels should be shifted upward.
Issue has been reported and next release will be correct.
Change-Id: I695fe8e24aff67d75e74635ba32a133342289eb4
Signed-off-by: Federico Recanati <federico.recanati@arm.com>
As Measured-Boot and Trusted-Boot are orthogonal, removed
Trusted-Boot's dependency on Measured-Boot by allowing them
to apply the Crypto module changes independently using the
CRYPTO_SUPPORT build flag.
Change-Id: I5a420e5d84f3fefe0c0092d822dab981e6390bbf
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Currently, the Event Log driver does platform layer work by invoking
a few platform functions in the 'event_log_finalise' call. Doing
platform work does not seem to be the driver's responsibility, hence
moved 'event_log_finalise' function's implementation to the platform
layer.
Alongside, introduced few Event Log driver functions and done
some cosmetic changes.
Change-Id: I486160e17e5b0677c734fd202af7ccd85476a551
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
VERBOSE print logs need a larger stack size and the currently configured
BL2 stack size was insufficient for FVP. This patch increases the same.
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Change-Id: I316ba2ea467571161b5f4807e6e5fa0bf89d44c6
We currently use ARM_PRELOADED_DTB_BASE build
variable to pass the kernel DTB base address to
the kernel when using the ARM_LINUX_KERNEL_AS_BL33
option. However this variable doesn't actually
change the DTB load address.
The DTB load address is actually specified in the
FW_CONFIG DTS (fvp_fw_config.dts) as 'hw_config'.
This patch passes the hw_config value instead of
ARM_PRELOADED_DTB_BASE allowing us to change
the kernel DTB load address through
fvp_fw_config.dts.
With this change we don't need the ARM_PRELOADED_DTB_BASE
build variable if RESET_TO_BL31 is not set.
Note that the hw_config value needs to be within the
ARM_DTB_DRAM_NS region specified by FVP_DTB_DRAM_MAP_START
and FVP_DTB_DRAM_MAP_SIZE.
This patch also expands the ARM_DTB_DRAM_NS region to 32MB.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: Idd74cdf5d2c649bb320644392ba5d69e175a53a9
The macros PLAT_HW_CONFIG_DTB_BASE and PLAT_HW_CONFIG_DTB_SIZE
describe the range of memory where the HW_CONFIG_DTB can be loaded
rather than the actual load address and size of the DTB. This patch
changes the names to something more descriptive.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I98b81f3ce0c80fd76614f959667c25b07941e190
When FEAT_RME is enabled, memory is divided into four Physical
Address Spaces (PAS): Root, Realm, Secure and Non-secure.
This patch introduces new carveouts for the Trusted SRAM and DRAM
for the FVP platform accordingly.
The following new regions are introduced with this change:
ARM_MAP_L0_GPT_REGION: Trusted SRAM region used to store Level 0
Granule Protection Table (GPT). This region resides in the Root PAS.
ARM_MAP_GPT_L1_DRAM: DRAM region used to store Level 1 GPT. It
resides in the Root PAS.
ARM_MAP_RMM_DRAM: DRAM region used to store RMM image. It
resides in the Realm PAS.
The L0 GPT is stored on Trusted SRAM next to firmware configuration
memory. The DRAM carveout when RME is enable is modified as follow:
--------------------
| |
| AP TZC (~28MB) |
--------------------
| |
| REALM (32MB) |
--------------------
| |
| EL3 TZC (3MB) |
--------------------
| L1 GPT + SCP TZC |
| (~1MB) |
0xFFFF_FFFF --------------------
During initialization of the TrustZone controller, Root regions
are configured as Secure regions. Then they are later reconfigured
to Root upon GPT initialization.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: If2e257141d51f51f715b70d4a06f18af53607254
This patch adds the necessary changes needed to build
and load RMM image for the FVP platform. RMM image is
loaded by BL2 after BL32 (if BL32 exists) and before BL33.
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I1ac9eade84c2e35c7479a322ca1d090b4e626819
TRP is a small test payload that implements Realm Monitor
Management (RMM) functionalities. RMM runs in the Realm world
(R-EL2) and manages the execution of Realm VMs and their
interaction with the hypervisor in Normal world.
TRP is used to test the interface between RMM and Normal world
software, known as Realm Management Interface (RMI). Current
functions includes returning RMM version and transitioning
granules from Non-secure to Realm world and vice versa.
More information about RMM can be found at:
https://developer.arm.com/documentation/den0125/latest
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: Ic7b9a1e1f3142ef6458d40150d0b4ba6bd723ea2
For Arm platforms PIE is enabled when RESET_TO_BL31=1 in aarch64 mode on
the similar lines enable PIE when RESET_TO_SP_MIN=1 in aarch32 mode.
The underlying changes for enabling PIE in aarch32 is submitted in
commit 4324a14bf
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ib8bb860198b3f97cdc91005503a3184d63e15469
Added GPT parser support in BL2 for Arm platforms to get the entry
address and length of the FIP in the GPT image.
Also, increased BL2 maximum size for FVP platform to successfully
compile ROM-enabled build with this change.
Verified this change using a patch:
https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/9654
Change-Id: Ie8026db054966653b739a82d9ba106d283f534d0
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Replaced PLAT_ARM_FIP_BASE and PLAT_ARM_FIP_MAX_SIZE macro with a
generic name PLAT_ARM_FLASH_IMAGE_BASE and PLAT_ARM_FLASH_IMAGE_MAX_SIZE
so that these macros can be reused in the subsequent GPT based support
changes.
Change-Id: I88fdbd53e1966578af4f1e8e9d5fef42c27b1173
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
To support platforms without Trusted DRAM this patch defines
PLAT_ARM_SPMC_BASE and enables platform to use either Trusted DRAM or
DRAM region behind TZC.
Change-Id: Icaa5c7d33334258ff27e8e0bfd0812c304e68ae4
Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Increased BL2 maximum size when CoT descriptors are placed
in device tree.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I6466d2841e189e7f15eb4f1a8db070542893cb5b
This patch adds support for Measured Boot functionality
to FVP platform code. It also defines new properties
in 'tpm_event_log' node to store Event Log address and
it size
'tpm_event_log_sm_addr'
'tpm_event_log_addr'
'tpm_event_log_size'
in 'event_log.dtsi' included in 'fvp_tsp_fw_config.dts'
and 'fvp_nt_fw_config.dts'. The node and its properties
are described in binding document
'docs\components\measured_boot\event_log.rst'.
Change-Id: I087e1423afcb269d6cfe79c1af9c348931991292
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
BL2 size gets increased due to the libfdt library update and
that eventually cause no-optimization build failure for BL2 as below:
aarch64-none-elf-ld.bfd: BL2 image has exceeded its limit.
aarch64-none-elf-ld.bfd: region `RAM' overflowed by 4096 bytes
Makefile:1070: recipe for target 'build/fvp/debug/bl2/bl2.elf' failed
make: *** [build/fvp/debug/bl2/bl2.elf] Error 1
Fixed build failure by increasing BL2 image size limit by 4Kb.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I92a57eb4db601561a98e254b64994bb921a88db3
Increased the size of firmware configuration area to accommodate
all configs.
Updated maximum size of following bootloaders due to increase
in firmware configs size and addition of the code in the BL2.
1. Increased maximum size of BL2 for Juno platform in no
optimisation case.
2. Reduced maximum size of BL31 for fvp and Juno platform.
3. Reduced maximum size of BL32 for Juno platform.
Change-Id: Ifba0564df0d1fe86175bed9fae87fdcf013b1831
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
This patch introduces dynamic configuration for SDEI setup and is supported
when the new build flag SDEI_IN_FCONF is enabled. Instead of using C arrays
and processing the configuration at compile time, the config is moved to
dts files. It will be retrieved at runtime during SDEI init, using the fconf
layer.
Change-Id: If5c35a7517ba00a9f258d7f3e7c8c20cee169a31
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
Co-authored-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
Increased the maximum size of BL2 image in order to
accommodate the BL2 image when TF-A build with no compiler
optimization for ARM platform.
Note: As of now, "no compiler optimization" build works
only when TRUSTED_BOOT_BOARD option is set to 0.
This change is verified using below CI configuration:
1. juno-no-optimize-default:juno-linux.uboot
2. fvp-no-optimize-default,fvp-default:fvp-tftf-fip.tftf-aemv8a-debug
Change-Id: I5932621237f8acd1b510682388f3ba78eae90ea4
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
