- 10 Jan, 2018 1 commit
-
-
Antonio Nino Diaz authored
Rename SP_VERSION macros to MM_VERSION, which is the name used in the MM specification [1]. Also, a few more helper macros have been added. MM-specific definitions have been moved to their own header file. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf Change-Id: Ia10e48c7e81a7a1f5eeca29a5270cae740a4a88a Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Jan, 2018 2 commits
-
-
Antonio Nino Diaz authored
The Secure Partition should be able to be used from any CPU, not just the lead one. This patch point the secure contexts of all secondary CPUs to the same one used by the lead CPU for the Secure Partition. This way, they can also use it. In order to prevent more than one CPU from using the Secure Partition at the same time, a lock has been added. Change-Id: Ica76373127c3626498b06c558a4874ce72201ff7 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Whether a Secure Partition is being initialized or not is something related to that specific partition, so it should be saved with the rest of the information related to it. Change-Id: Ie8a780f70df83fb03ef9c01ba37960208d9b5319 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 12 Dec, 2017 1 commit
-
-
Sandrine Bailleux authored
This partially reverts commit d6b532b5 , keeping only the fixes to the assertions. The changes related to the order of arguments passed to the secure partition were not correct and violated the specification of the SP_EVENT_COMPLETE SMC. This patch also improves the MM_COMMUNICATE argument validation. The cookie argument, as it comes from normal world, can't be trusted and thus needs to always be validated at run time rather than using an assertion. Also validate the communication buffer address and return INVALID_PARAMETER if it is zero, as per the MM specification. Fix a few typos in comments and use the "secure partition" terminology rather than "secure payload". Change-Id: Ice6b7b5494b729dd44611f9a93d362c55ab244f7 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 06 Dec, 2017 2 commits
-
-
Antonio Nino Diaz authored
A new platform define, `PLAT_SP_IMAGE_XLAT_SECTION_NAME`, has been introduced to select the section where the translation tables used by the S-EL1/S-EL0 are placed. This define has been used to move the translation tables to DRAM secured by TrustZone. Most of the extra needed space in BL31 when SPM is enabled is due to the large size of the translation tables. By moving them to this memory region we can save 44 KiB. A new argument has been added to REGISTER_XLAT_CONTEXT2() to specify the region where the translation tables have to be placed by the linker. Change-Id: Ia81709b4227cb8c92601f0caf258f624c0467719 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Common code mustn't include ARM platforms headers. Change-Id: Ib6e4f5a77c2d095e6e8c3ad89c89cb1959cd3043 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 05 Dec, 2017 2 commits
-
-
Sandrine Bailleux authored
Rename SP_COMMUNICATE_AARCH32/AARCH64 into MM_COMMUNICATE_AARCH32/AARCH64 to align with the MM specification [1]. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf Change-Id: I478aa4024ace7507d14a5d366aa8e20681075b03 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Antonio Nino Diaz authored
The defines have been renamed to match the names used in the documentation. Change-Id: I2f18b65112d2db040a89d5a8522e9790c3e21628 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 Nov, 2017 2 commits
-
-
Antonio Nino Diaz authored
The parameters passed to the Secure world from the Secure Partition Manager when invoking SP_COMMUNICATE_AARCH32/64 were incorrect, as well as the checks done on them. Change-Id: I26e8c80cad0b83437db7aaada3d0d9add1c53a78 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
The code was incorrectly reading from ID_AA64PRF0_EL1 instead of ID_AA64MMFR0_EL1 causing the supported granularity sizes returned by the code to be wrong. This wasn't causing any problem because it's just used to check the alignment of the base of the buffer shared between Non-secure and Secure worlds, and it was aligned to more than 64 KiB, which is the maximum granularity supported by the architecture. Change-Id: Icc0d949d9521cc0ef13afb753825c475ea62d462 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 10 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
The MP info struct is placed right after the boot info struct. However, when calculating the address of the MP info, the size of the boot info struct was being multiplied by the size of the MP boot info. This left a big gap of empty space between the structs. This didn't break any code because the boot info struct has a pointer to the MP info struct. It was just wasting space. Change-Id: I1668e3540d9173261968f6740623549000bd48db Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-