1. 06 Feb, 2018 2 commits
    • Jeenu Viswambharan's avatar
      TSPD: Require NS preemption along with EL3 exception handling · 6027796f
      Jeenu Viswambharan authored
      
      
      At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
      Non-secure interrupt affects TSPs execution. When TSP is executing:
      
        1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
           at the TSP's exception vector, and TSP voluntarily preempts itself.
      
        2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
           trap to EL3, which preempts TSP execution.
      
      When EL3 exception handling is in place (i.e.,
      EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
      with GICv3, pending NS interrupts while TSP is executing will be
      signalled as FIQ (which traps to EL3). This situation necessitates the
      same treatment applied to case (2) above.
      
      Therefore, when EL3 exception handling is in place, additionally
      require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.
      
      Strictly speaking, this is not required on a system with GICv2, but the
      same model is uniformly followed regardless, for simplicity.
      
      Relevant documentation updated.
      
      Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      6027796f
    • Jeenu Viswambharan's avatar
      TSPD: Explicitly allow NS preemption for Yielding SMCs · 1dd022ca
      Jeenu Viswambharan authored
      
      
      When EL3 exception handling is in effect (i.e.,
      EL3_EXCEPTION_HANDLING=1), Non-secure interrupts can't preempt Secure
      execution. However, for yielding SMCs, preemption by Non-secure
      interupts is intended.
      
      This patch therefore adds a call to ehf_allow_ns_preemption() before
      dispatching a Yielding SMC to TSP.
      
      Change-Id: Ia3a1ae252f3adc0f14e6d7e0502f251bdb349bdf
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1dd022ca
  2. 29 Jan, 2018 1 commit
  3. 10 Jan, 2018 1 commit
  4. 09 Jan, 2018 1 commit
  5. 08 Jan, 2018 2 commits
  6. 12 Dec, 2017 1 commit
    • Sandrine Bailleux's avatar
      SPM: Fix MM_COMMUNICATE_AARCH32/64 parameters · 4d2787ce
      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: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      4d2787ce
  7. 06 Dec, 2017 3 commits
  8. 05 Dec, 2017 2 commits
  9. 20 Nov, 2017 2 commits
  10. 15 Nov, 2017 2 commits
  11. 13 Nov, 2017 3 commits
  12. 10 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Fix pointer to MP info in boot info struct · ff7d0805
      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: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      ff7d0805
  13. 08 Nov, 2017 2 commits
    • 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
    • Antonio Nino Diaz's avatar
      spd: Use `ENABLE_ASSERTIONS` instead of `DEBUG` · 92cad5fa
      Antonio Nino Diaz authored
      A line in the upstream SPDs is only compiled in in `DEBUG` builds. This
      line is used to help with assertions and so assertion failures can
      happen in release builds with assertions enabled. Use
      `ENABLE_ASSERTIONS` instead of `DEBUG`.
      
      This bug was introduced in commit aa61368e
      
      , which introduced the build
      option `ENABLE_ASSERTIONS`.
      
      Change-Id: I7977df9c89c68677b00099b2a1926fa3cb0937c6
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      92cad5fa
  14. 19 Sep, 2017 1 commit
    • Aijun Sun's avatar
      trusty: save/restore FPU registers in world switch · ab609e1a
      Aijun Sun authored
      
      
      Currently, Trusty OS/LK implemented FPU context switch in internal
      thread switch but does not implement the proper mechanism for world
      switch. This commit just simply saves/restores FPU registes in world
      switch to prevent FPU context from being currupted when Trusty OS uses
      VFP in its applications.
      
      It should be noted that the macro *CTX_INCLUDE_FPREGS* must be defined
      in trusty.mk if Trusty OS uses VFP
      Signed-off-by: default avatarAijun Sun <aijun.sun@spreadtrum.com>
      ab609e1a
  15. 24 Aug, 2017 1 commit
  16. 09 Aug, 2017 1 commit
    • Edison Ai's avatar
      Support paging function for OPTEE. · d59a6acc
      Edison Ai authored
      
      
      ARM TF need transfer information about pageable image load address
      and memory limit to OPTEE. OPTEE will relocate the pageable image
      to where it's needed.
      The legacy OP-TEE images that do not include header information
      are not affected.
      
      Change-Id: Id057efbbc894de7c36b2209b391febea4729c455
      Signed-off-by: default avatarEdison Ai <edison.ai@arm.com>
      d59a6acc
  17. 12 Jul, 2017 1 commit
    • Isla Mitchell's avatar
      Fix order of #includes · 2a4b4b71
      Isla Mitchell authored
      
      
      This fix modifies the order of system includes to meet the ARM TF coding
      standard. There are some exceptions in order to retain header groupings,
      minimise changes to imported headers, and where there are headers within
      the #if and #ifndef statements.
      
      Change-Id: I65085a142ba6a83792b26efb47df1329153f1624
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      2a4b4b71
  18. 14 Jun, 2017 1 commit
  19. 04 May, 2017 1 commit
  20. 03 May, 2017 1 commit
  21. 26 Apr, 2017 1 commit
  22. 20 Apr, 2017 1 commit
    • Antonio Nino Diaz's avatar
      tspd:FWU:Fix usage of SMC_RET0 · 7a317a70
      Antonio Nino Diaz authored
      
      
      SMC_RET0 should only be used when the SMC code works as a function that
      returns void. If the code of the SMC uses SMC_RET1 to return a value to
      signify success and doesn't return anything in case of an error (or the
      other way around) SMC_RET1 should always be used to return clearly
      identifiable values.
      
      This patch fixes two cases in which the code used SMC_RET0 instead of
      SMC_RET1.
      
      It also introduces the define SMC_OK to use when an SMC must return a
      value to tell that it succeeded, the same way as SMC_UNK is used in case
      of failure.
      
      Change-Id: Ie4278b51559e4262aced13bbde4e844023270582
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      7a317a70
  23. 06 Mar, 2017 7 commits
  24. 23 Feb, 2017 1 commit