1. 11 Dec, 2018 3 commits
  2. 10 Dec, 2018 2 commits
  3. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  4. 22 Aug, 2018 1 commit
  5. 20 Aug, 2018 1 commit
  6. 21 Jun, 2018 2 commits
    • Jeenu Viswambharan's avatar
      SDEI: Make dispatches synchronous · cdb6ac94
      Jeenu Viswambharan authored
      
      
      SDEI event dispatches currently only sets up the Non-secure context
      before returning to the caller. The actual dispatch only happens upon
      exiting EL3 next time.
      
      However, for various error handling scenarios, it's beneficial to have
      the dispatch happen synchronously. I.e. when receiving SDEI interrupt,
      or for a successful sdei_dispatch_event() call, the event handler is
      executed; and upon the event completion, dispatcher execution resumes
      after the point of dispatch. The jump primitives introduced in the
      earlier patch facilitates this feature.
      
      With this patch:
      
        - SDEI interrupts and calls to sdei_dispatch_event prepares the NS
          context for event dispatch, then sets a jump point, and immediately
          exits EL3. This results in the client handler executing in
          Non-secure.
      
        - When the SDEI client completes the dispatched event, the SDEI
          dispatcher does a longjmp to the jump pointer created earlier. For
          the caller of the sdei_dispatch_event() in particular, this would
          appear as if call returned successfully.
      
      The dynamic workaround for CVE_2018_3639 is slightly shifted around as
      part of related minor refactoring. It doesn't affect the workaround
      functionality.
      
      Documentation updated.
      
      NOTE: This breaks the semantics of the explicit dispatch API, and any
      exiting usages should be carefully reviewed.
      
      Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      cdb6ac94
    • Jeenu Viswambharan's avatar
      SDEI: Allow platforms to define explicit events · af2c9ecd
      Jeenu Viswambharan authored
      
      
      The current macros only allow to define dynamic and statically-bound
      SDEI events. However, there ought be a mechanism to define SDEI events
      that are explicitly dispatched; i.e., events that are dispatched as a
      result of a previous secure interrupt or other exception
      
      This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit
      event. They must be placed under private mappings. Only the priority
      flags are allowed to be additionally specified.
      
      Documentation updated.
      
      Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      af2c9ecd
  7. 20 Jun, 2018 1 commit
  8. 13 Jun, 2018 1 commit
    • Sandrine Bailleux's avatar
      SPM: Treat SP xlat tables the same as others · d801a1d0
      Sandrine Bailleux authored
      The translation tables allocated for the Secure Partition do not need
      to be treated as a special case. They can be put amongst the other
      tables mapping BL31's general purpose memory. They will be mapped with
      the same attributes as them, which is fine.
      
      The explicit alignment constraint in BL31's linker script to pad the
      last page of memory allocated to the Secure Partition's translation
      tables is useless too, as page tables are per se pages, thus their
      end address is naturally aligned on a page-boundary.
      
      In fact, this patch does not change the existing behaviour. Since
      patch 22282bb6
      
       ("SPM: Move all SP-related info to SP context
      struct"), the secure_partition.c file has been renamed into sp_xlat.c
      but the linker script has not been properly updated. As a result, the
      SP translation tables are not specifically put at the start of the
      xlat_table linker section, the __SP_IMAGE_XLAT_TABLES_START__/_END__
      symbols have the same value, the size of the resulting mmap_region
      covering these xlat tables is 0 and so it is ignored.
      
      Change-Id: I4cf0a4cc090298811cca53fc9cee74df0f2b1512
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      d801a1d0
  9. 23 May, 2018 2 commits
    • Antonio Nino Diaz's avatar
      SPM: Move all SP-related info to SP context struct · 22282bb6
      Antonio Nino Diaz authored
      
      
      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: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      22282bb6
    • Dimitris Papastamos's avatar
      Implement static workaround for CVE-2018-3639 · b8a25bbb
      Dimitris Papastamos authored
      For affected CPUs, this approach enables the mitigation during EL3
      initialization, following every PE reset. No mechanism is provided to
      disable the mitigation at runtime.
      
      This approach permanently mitigates the entire software stack and no
      additional mitigation code is required in other software components.
      
      TF-A implements this approach for the following affected CPUs:
      
      *   Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of
          `CPUACTLR_EL1` (`S3_1_C15_C2_0`).
      
      *   Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the
          Technical Reference Manual (TRM)).
      
      *   Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1`
          (`S3_0_C15_C1_0`).
      
      Additionally, a new SMC interface is implemented to allow software
      executing in lower ELs to discover whether the system is mitigated
      against CVE-2018-3639.
      
      Refer to "Firmware interfaces for mitigating cache speculation
      vulnerabilities System Software on Arm Systems"[0] for more
      information.
      
      [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
      
      
      
      Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      b8a25bbb
  10. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      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: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  11. 29 Jan, 2018 1 commit
  12. 22 Jan, 2018 1 commit
  13. 10 Jan, 2018 1 commit
  14. 05 Dec, 2017 2 commits
  15. 20 Nov, 2017 1 commit
  16. 13 Nov, 2017 2 commits
  17. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      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: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
      Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  18. 03 May, 2017 1 commit
  19. 22 Sep, 2016 1 commit
    • Soby Mathew's avatar
      PSCI: Do psci_setup() as part of std_svc_setup() · 58e946ae
      Soby Mathew authored
      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
      58e946ae
  20. 19 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce PSCI Library Interface · cf0b1492
      Soby Mathew authored
      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
      cf0b1492
  21. 18 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Introduce `el3_runtime` and `PSCI` libraries · 532ed618
      Soby Mathew authored
      This patch moves the PSCI services and BL31 frameworks like context
      management and per-cpu data into new library components `PSCI` and
      `el3_runtime` respectively. This enables PSCI to be built independently from
      BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
      PSCI library sources and gets included by `bl31.mk`. Other changes which
      are done as part of this patch are:
      
      * The runtime services framework is now moved to the `common/` folder to
        enable reuse.
      * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
        specific folder.
      * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
        to `plat/common` folder. The original file location now has a stub which
        just includes the file from new location to maintain platform compatibility.
      
      Most of the changes wouldn't affect platform builds as they just involve
      changes to the generic bl1.mk and bl31.mk makefiles.
      
      NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
      THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
      MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.
      
      Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
      532ed618