GitLab

The function xlat_arch_is_granule_size_supported() can be used to check
if a specific granule size is supported. In Armv8, AArch32 only supports
4 KiB pages. AArch64 supports 4 KiB, 16 KiB or 64 KiB depending on the
implementation, which is detected at runtime.

The function xlat_arch_get_max_supported_granule_size() returns the max
granule size supported by the implementation.

Even though right now they are only used by SPM, they may be useful in
other places in the future. This patch moves the code currently in SPM
to the xlat tables lib so that it can be reused.

Change-Id: If54624a5ecf20b9b9b7f38861b56383a03bbc8a4
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

In the context management library, cm_setup_context() takes the
information in ep_info to fill the registers x0-x7. This patch replaces
the current code that sets them manually by the correct initialization
code.

Change-Id: Id1fdf4681b154026c2e3af1f9b05b19582b7d16d
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

When dynamic mitigation is used, the SDEI handler is required to
execute with the mitigation enabled by default, regardless of the
mitigation state for lower ELs.  This means that if the kernel or
hypervisor explicitly disables the mitigation and then later when the
event is dispatched, the dispatcher will remember the mitigation state
for the lower ELs but force the mitigation to be on during the SDEI
handler execution.  When the SDEI handler returns, it will restore the
mitigation state.

This behaviour is described in "Firmware interfaces for mitigating
cache speculation vulnerabilities System Software on Arm Systems"[0].

[0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification



Change-Id: I8dd60b736be0aa9e832b0f92d67a401fdeb417f4
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

Simplify the code of the SMC handler by extracting the code of
SP_EVENT_COMPLETE and MM_COMMUNICATE.

Change-Id: I9250a3f5e4b807b35c9d044592c1074a45ab9a07
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Instead of just knowing if the Secure Partition is being initialized or
not, this generic state enum can be used to tell if the Secure Partition
is busy and to add more states in the future if needed.

Also, the spinlock of the secure_partition_context_t structure now only
protects against concurrent accesses to the state of the secure
partition. Previously, it used to lock down the whole structure, thus
preventing one CPU to access any of its fields while another CPU was
executing the partition.

Change-Id: I51215328e2ca8ea2452f92e4a1cb237415958b22
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

The current internal names are too long, which makes it hard to write
code as many lines overflow the limit and need to be split, which may
not help the reader.

Change-Id: I072bdc8f3dd125255063ffa7f02500e5228fc9a1
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

This is done in order to make it easier to read the file spm_main.c.

Change-Id: I21e765154c1682a319a3bc47a19a42fd736e910e
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Move all information related to a Secure Partition to the struct
secure_partition_context_t.

This requires an in-depth refactor because most of the previous code of
SPM relied on global information.

Change-Id: I0a23e93817dcc191ce1d7506b8bc671d376123c4
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

This allows secure partitions to access these registers. This is
needed in some cases. For example, it has been reported that in order
to implement secure storage services, a secure partition needs to
encrypt/decrypt some authentication variables, which requires FP/SIMD
support.

Note that SPM will not do any saving/restoring of these registers on
behalf of the SP. This falls under the SP's responsibility.

Also note that if the SP gets preempted, it might not get a chance to
save/restore FP/SIMD registers first. This patch does not address this
problem. It only serves as a temporary solution to unblock development
on the secure partition side.

Change-Id: I3b8ccdebdac0219f6ac96ad66ab2be0be8374ad3
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Change-Id: I989c1f4aef8e3cb20d5d19e6347575e6449bb60b
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Void pointers have been used to access linker symbols, by declaring an
extern pointer, then taking the address of it. This limits symbols
values to aligned pointer values. To remove this restriction an
IMPORT_SYM macro has been introduced, which declares it as a char
pointer and casts it to the required type.

Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>

Ensure (where possible) that switch statements in services comply with
MISRA rules 16.1 - 16.7.

Change-Id: I47bf6ed4a026201e6fe125ce51842482e99e8bb0
Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>

When the source code says 'SMCC' it is talking about the SMC Calling
Convention. The correct acronym is SMCCC. This affects a few definitions
and file names.

Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S)
but the old files have been kept for compatibility, they include the
new ones with an ERROR_DEPRECATED guard.

Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Rule 8.4: A compatible declaration shall be visible when
          an object or function with external linkage is defined.

Change-Id: I26e042cb251a6f9590afa1340fdac73e42f23979
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

Currently, when the client attempts to do SDEI_EVENT_COMPLETE or
SDEI_EVENT_COMPLETE_AND_RESUME, the dispatcher pops off the outstanding
dispatch context for sanity check. There are however other checks
following this, which could potentially return failure. If that happens,
by popping the context, the dispatcher has inadvertently discarded a
valid context.

This patch fixes this bug by inspecting (not actually popping) the
outstanding context. The context is popped only after all error checks
are completed.

Change-Id: Ie199f6442f871a8177a8247a0c646543bad76d21
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

After executing a TLBI a DSB is needed to ensure completion of the
TLBI.

rk3328: The MMU is allowed to load TLB entries for as long as it is
enabled. Because of this, the correct place to execute a TLBI is right
after disabling the MMU.

Change-Id: I8280f248d10b49a8c354a4ccbdc8f8345ac4c170
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

This fixes all defects according to MISRA Rule 3.1: "The character
sequences /* and // shall not be used within a comment". This affects
all URLs in comments, so they have been removed:

- The link in `sdei_state.c` can also be found in the documentation file
  `docs/sdei.rst`.

- The bug that the file `io_fip.c` talks about doesn't affect the
  currently supported version of GCC, so it doesn't make sense to keep
  the comment. Note that the version of GCC officially supported is the
  one that comes with Linaro Release 17.10, which is GCC 6.2.

- The link in `tzc400.c` was broken, and it didn't correctly direct to
  the Technical Reference Manual it should. The link has been replaced
  by the title of the document, which is more convenient when looking
  for the document.

Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

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>

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>

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>

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>

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>

Common code mustn't include ARM platforms headers.

Change-Id: Ib6e4f5a77c2d095e6e8c3ad89c89cb1959cd3043
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

At present, both SDEI_PRIVATE_RESET and SDEI_SHARED_RESET returns
SDEI_PENDING if they fail to unregister an event. The SDEI specification
however requires that the APIs return SDEI_EDENY in these cases. This
patch fixes the return codes for the reset APIs.

Change-Id: Ic14484c91fa8396910387196c256d1ff13d03afd
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

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>

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>

The SDEI specification requires that binding a client interrupt
dispatches SDEI Normal priority event. This means that dynamic events
can't have Critical priority. Add asserts for this.

Change-Id: I0bdd9e0e642fb2b61810cb9f4cbfbd35bba521d1
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Change-Id: Ic381ab5d03ec68c7f6e8d357ac2e2cbf0cc6b2e8
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

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>

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>

Change-Id: Iee617a3528225349b6eede2f8abb26da96640678
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

This allows for other EL3 components to schedule an SDEI event dispatch
to Normal world upon the next ERET. The API usage constrains are set out
in the SDEI dispatcher documentation.

Documentation to follow.

Change-Id: Id534bae0fd85afc94523490098c81f85c4e8f019
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].

Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
BL31.

Update user guide and porting guide. SDEI documentation to follow.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf



Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

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>

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>

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by FreeBSD have not been modified.

[0]: https://spdx.org/



Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

Without an explicit cache flush, the next timestamp captured might have
a bogus value.

This can happen if the following operations happen in order,
on a CPU that's being powered down.

1) ENTER PSCI timestamp is captured with caches enabled.

2) The next timestamp (ENTER_HW_LOW_PWR) is captured with caches
   disabled.

3) On a system that uses a write-back cache configuration, the
   cache line that holds the PMF timestamps is evicted.

After step 1), the ENTER_PSCI timestamp is cached and not in main memory.
After step 2), the ENTER_HW_LOW_PWR timestamp is stored in main memory.
Before the CPU power down happens, the hardware evicts the cache line that
contains the PMF timestamps for this service.  As a result, the timestamp
captured in step 2) is overwritten with a bogus value.

Change-Id: Ic1bd816498d1a6d4dc16540208ed3a5efe43f529
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

In order to quantify the overall time spent in the PSCI software
implementation, an initial collection of PMF instrumentation points
has been added.

Instrumentation has been added to the following code paths:

- Entry to PSCI SMC handler.  The timestamp is captured as early
  as possible during the runtime exception and stored in memory
  before entering the PSCI SMC handler.

- Exit from PSCI SMC handler.  The timestamp is captured after
  normal return from the PSCI SMC handler or if a low power state
  was requested it is captured in the bl31 warm boot path before
  return to normal world.

- Entry to low power state.  The timestamp is captured before entry
  to a low power state which implies either standby or power down.
  As these power states are mutually exclusive, only one timestamp
  is defined to describe both.  It is possible to differentiate between
  the two power states using the PSCI STAT interface.

- Exit from low power state.  The timestamp is captured after a standby
  or power up operation has completed.

To calculate the number of cycles spent running code in Trusted Firmware
one can perform the following calculation:

(exit_psci - enter_psci) - (exit_low_pwr - enter_low_pwr).

The resulting number of cycles can be converted to time given the
frequency of the counter.

Change-Id: Ie3b8f3d16409b6703747093b3a2d5c7429ad0166
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

This patch moves the invocation of `psci_setup()` from BL31 and SP_MIN
into `std_svc_setup()` as part of ARM Standard Service initialization.
This allows us to consolidate ARM Standard Service initializations which
will be added to in the future. A new function `get_arm_std_svc_args()`
is introduced to get arguments corresponding to each standard service.
This function must be implemented by the EL3 Runtime Firmware and both
SP_MIN and BL31 implement it.

Change-Id: I38e1b644f797fa4089b20574bd4a10f0419de184

This patch introduces the PSCI Library interface. The major changes
introduced are as follows:

* Earlier BL31 was responsible for Architectural initialization during cold
boot via bl31_arch_setup() whereas PSCI was responsible for the same during
warm boot. This functionality is now consolidated by the PSCI library
and it does Architectural initialization via psci_arch_setup() during both
cold and warm boots.

* Earlier the warm boot entry point was always `psci_entrypoint()`. This was
not flexible enough as a library interface. Now PSCI expects the runtime
firmware to provide the entry point via `psci_setup()`. A new function
`bl31_warm_entrypoint` is introduced in BL31 and the previous
`psci_entrypoint()` is deprecated.

* The `smc_helpers.h` is reorganized to separate the SMC Calling Convention
defines from the Trusted Firmware SMC helpers. The former is now in a new
header file `smcc.h` and the SMC helpers are moved to Architecture specific
header.

* The CPU context is used by PSCI for context initialization and
restoration after power down (PSCI Context). It is also used by BL31 for SMC
handling and context management during Normal-Secure world switch (SMC
Context). The `psci_smc_handler()` interface is redefined to not use SMC
helper macros thus enabling to decouple the PSCI context from EL3 runtime
firmware SMC context. This enables PSCI to be integrated with other runtime
firmware using a different SMC context.

NOTE: With this patch the architectural setup done in `bl31_arch_setup()`
is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be
invoked prior to architectural setup. It is highly unlikely that the platform
setup will depend on architectural setup and cause any failure. Please be
be aware of this change in sequence.

Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73