1. 11 Jan, 2018 7 commits
    • Dimitris Papastamos's avatar
      Add hooks to save/restore AMU context for Cortex A75 · 53bfb94e
      Dimitris Papastamos authored
      
      
      Change-Id: I504d3f65ca5829bc1f4ebadb764931f8379ee81f
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      53bfb94e
    • Dimitris Papastamos's avatar
      AMU: Add hooks to save/restore AMU context · b6eb3932
      Dimitris Papastamos authored
      
      
      On some systems, the AMU counters might reset to 0 when a CPU
      powerdown happens.  This behaviour conflicts with the intended
      use-case of AMU as lower ELs are only expected to see non-decreasing
      counter values.
      
      Change-Id: If25519965d4e6e47e09225d0e732947986cbb5ec
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      b6eb3932
    • Dimitris Papastamos's avatar
      AMU: Add configuration helpers for aarch64 · 0767d50e
      Dimitris Papastamos authored
      
      
      Add some AMU helper functions to allow configuring, reading and
      writing of the Group 0 and Group 1 counters.  Documentation for these
      helpers will come in a separate patch.
      
      Change-Id: I656e070d2dae830c22414f694aa655341d4e2c40
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      0767d50e
    • Dimitris Papastamos's avatar
      AMU: Add plat interface to select which group 1 counters to enable · 59902b7c
      Dimitris Papastamos authored
      
      
      A new platform macro `PLAT_AMU_GROUP1_COUNTERS_MASK` controls which
      group 1 counters should be enabled. The maximum number of group 1
      counters supported by AMUv1 is 16 so the mask can be at most 0xffff.
      If the platform does not define this mask, no group 1 counters are
      enabled.
      
      A related platform macro `PLAT_AMU_GROUP1_NR_COUNTERS` is used by
      generic code to allocate an array to save and restore the counters on
      CPU suspend.
      
      Change-Id: I6d135badf4846292de931a43bb563077f42bb47b
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      59902b7c
    • Dimitris Papastamos's avatar
      Add PubSub events for CPU powerdown/powerup · 7593252c
      Dimitris Papastamos authored
      
      
      The suspend hook is published at the start of a CPU powerdown
      operation.  The resume hook is published at the end of a CPU powerup
      operation.
      
      Change-Id: I50c05e2dde0d33834095ac41b4fcea4c161bb434
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      7593252c
    • Dimitris Papastamos's avatar
      Use PFR0 to identify need for mitigation of CVE-2017-5915 · 780edd86
      Dimitris Papastamos authored
      
      
      If the CSV2 field reads as 1 then branch targets trained in one
      context cannot affect speculative execution in a different context.
      In that case skip the workaround on Cortex A75.
      
      Change-Id: I4d5504cba516a67311fb5f0657b08f72909cbd38
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      780edd86
    • Dimitris Papastamos's avatar
      Workaround for CVE-2017-5715 on Cortex A73 and A75 · a1781a21
      Dimitris Papastamos authored
      
      
      Invalidate the Branch Target Buffer (BTB) on entry to EL3 by
      temporarily dropping into AArch32 Secure-EL1 and executing the
      `BPIALL` instruction.
      
      This is achieved by using 3 vector tables.  There is the runtime
      vector table which is used to handle exceptions and 2 additional
      tables which are required to implement this workaround.  The
      additional tables are `vbar0` and `vbar1`.
      
      The sequence of events for handling a single exception is
      as follows:
      
      1) Install vector table `vbar0` which saves the CPU context on entry
         to EL3 and sets up the Secure-EL1 context to execute in AArch32 mode
         with the MMU disabled and I$ enabled.  This is the default vector table.
      
      2) Before doing an ERET into Secure-EL1, switch vbar to point to
         another vector table `vbar1`.  This is required to restore EL3 state
         when returning from the workaround, before proceeding with normal EL3
         exception handling.
      
      3) While in Secure-EL1, the `BPIALL` instruction is executed and an
         SMC call back to EL3 is performed.
      
      4) On entry to EL3 from Secure-EL1, the saved context from step 1) is
         restored.  The vbar is switched to point to `vbar0` in preparation to
         handle further exceptions.  Finally a branch to the runtime vector
         table entry is taken to complete the handling of the original
         exception.
      
      This workaround is enabled by default on the affected CPUs.
      
      NOTE
      ====
      
      There are 4 different stubs in Secure-EL1.  Each stub corresponds to
      an exception type such as Sync/IRQ/FIQ/SError.  Each stub will move a
      different value in `R0` before doing an SMC call back into EL3.
      Without this piece of information it would not be possible to know
      what the original exception type was as we cannot use `ESR_EL3` to
      distinguish between IRQs and FIQs.
      
      Change-Id: I90b32d14a3735290b48685d43c70c99daaa4b434
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      a1781a21
  2. 06 Dec, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Move S-EL1/S-EL0 xlat tables to TZC DRAM · 45d640f0
      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: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      45d640f0
  3. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Enable SVE for Non-secure world · 1a853370
      David Cunado authored
      
      
      This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
      to one EL3 will check to see if the Scalable Vector Extension (SVE) is
      implemented when entering and exiting the Non-secure world.
      
      If SVE is implemented, EL3 will do the following:
      
      - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.
      
      - Exit from Non-secure world: SIMD, FP and SVE functionality is
        disabled. As SIMD and FP registers are part of the SVE Z-registers
        then any use of SIMD / FP functionality would corrupt the SVE
        registers.
      
      The build option default is 1. The SVE functionality is only supported
      on AArch64 and so the build option is set to zero when the target
      archiecture is AArch32.
      
      This build option is not compatible with the CTX_INCLUDE_FPREGS - an
      assert will be raised on platforms where SVE is implemented and both
      ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.
      
      Also note this change prevents secure world use of FP&SIMD registers on
      SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
      such platforms unless ENABLE_SVE_FOR_NS is set to 0.
      
      Additionally, on the first entry into the Non-secure world the SVE
      functionality is enabled and the SVE Z-register length is set to the
      maximum size allowed by the architecture. This includes the use case
      where EL2 is implemented but not used.
      
      Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      1a853370
  4. 29 Nov, 2017 3 commits
  5. 20 Nov, 2017 1 commit
    • Dimitris Papastamos's avatar
      Refactor Statistical Profiling Extensions implementation · 281a08cc
      Dimitris Papastamos authored
      
      
      Factor out SPE operations in a separate file.  Use the publish
      subscribe framework to drain the SPE buffers before entering secure
      world.  Additionally, enable SPE before entering normal world.
      
      A side effect of this change is that the profiling buffers are now
      only drained when a transition from normal world to secure world
      happens.  Previously they were drained also on return from secure
      world, which is unnecessary as SPE is not supported in S-EL1.
      
      Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
      Signed-off-by: default avatarDimitris Papastamos <dimitris.papastamos@arm.com>
      281a08cc
  6. 17 Nov, 2017 1 commit
  7. 15 Nov, 2017 1 commit
    • David Cunado's avatar
      Move FPEXC32_EL2 to FP Context · 91089f36
      David Cunado authored
      
      
      The FPEXC32_EL2 register controls SIMD and FP functionality when the
      lower ELs are executing in AArch32 mode. It is architecturally mapped
      to AArch32 system register FPEXC.
      
      This patch removes FPEXC32_EL2 register from the System Register context
      and adds it to the floating-point context. EL3 only saves / restores the
      floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1.
      
      The rationale for this change is that if the Secure world is using FP
      functionality and EL3 is not managing the FP context, then the Secure
      world will save / restore the appropriate FP registers.
      
      NOTE - this is a break in behaviour in the unlikely case that
      CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32
      Secure Payload that modifies FPEXC, but does not save and restore
      this register
      
      Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      91089f36
  8. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      ARM platforms: Provide SDEI entry point validation · 781f4aac
      Jeenu Viswambharan authored
      
      
      Provide a strong definition for plat_sdei_validate_sdei_entrypoint()
      which translates client address to Physical Address, and then validating
      the address to be present in DRAM.
      
      Change-Id: Ib93eb66b413d638aa5524d1b3de36aa16d38ea11
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      781f4aac
    • Jeenu Viswambharan's avatar
      BL31: Introduce Exception Handling Framework · 21b818c0
      Jeenu Viswambharan authored
      
      
      EHF is a framework that allows dispatching of EL3 interrupts to their
      respective handlers in EL3.
      
      This framework facilitates the firmware-first error handling policy in
      which asynchronous exceptions may be routed to EL3. Such exceptions may
      be handed over to respective exception handlers. Individual handlers
      might further delegate exception handling to lower ELs.
      
      The framework associates the delegated execution to lower ELs with a
      priority value. For interrupts, this corresponds to the priorities
      programmed in GIC; for other types of exceptions, viz. SErrors or
      Synchronous External Aborts, individual dispatchers shall explicitly
      associate delegation to a secure priority. In order to prevent lower
      priority interrupts from preempting higher priority execution, the
      framework provides helpers to control preemption by virtue of
      programming Priority Mask register in the interrupt controller.
      
      This commit allows for handling interrupts targeted at EL3. Exception
      handlers own interrupts by assigning them a range of secure priorities,
      and registering handlers for each priority range it owns.
      
      Support for exception handling in BL31 image is enabled by setting the
      build option EL3_EXCEPTION_HANDLING=1.
      
      Documentation to follow.
      
      NOTE: The framework assumes the priority scheme supported by platform
      interrupt controller is compliant with that of ARM GIC architecture (v2
      or later).
      
      Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      21b818c0
  9. 08 Nov, 2017 11 commits
  10. 01 Nov, 2017 1 commit
  11. 31 Oct, 2017 2 commits
  12. 23 Oct, 2017 2 commits
  13. 17 Oct, 2017 4 commits
  14. 16 Oct, 2017 3 commits