1. 23 Jul, 2021 1 commit
    • Daniel Boulby's avatar
      fix(sdei): set SPSR for SDEI based on TakeException · 37596fcb
      Daniel Boulby authored
      
      
      The SDEI specification now says that during an SDEI
      event handler dispatch the SPSR should be set according
      to the TakeException() pseudocode function defined in
      the Arm Architecture Reference Manual. This patch sets
      the SPSR according to the function given in
      ARM DDI 0487F.c page J1-7635
      
      Change-Id: Id2f8f2464fd69c701d81626162827e5c4449b658
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      37596fcb
  2. 08 Feb, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Make setjmp.h prototypes comply with the C standard · e0566305
      Antonio Nino Diaz authored
      
      
      Instead of having a custom implementation of setjmp() and longjmp() it
      is better to follow the C standard.
      
      The comments in setjmp.h are no longer needed as there are no deviations
      from the expected one, so they have been removed.
      
      All SDEI code that relied on them has been fixed to use the new function
      prototypes and structs.
      
      Change-Id: I6cd2e21cb5a5bcf81ba12283f2e4c067bd5172ca
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e0566305
  3. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  4. 26 Nov, 2018 1 commit
    • Jeenu Viswambharan's avatar
      SDEI: Unconditionally resume Secure if it was interrupted · 90a9213b
      Jeenu Viswambharan authored
      
      
      Secure world execution nearly always expect a controlled exit to
      Non-secure world. SDEI interrupts, although targets EL3, occur on behalf
      of Non-secure world, and may have higher priority than Secure world
      interrupts. Therefore they might preempt Secure execution, and yield
      execution to Non-secure SDEI handler. Upon completion of SDEI event
      handling (regardless of whether it's COPLETE or COMPLETE_AND_RESUME), we
      must resume Secure execution if it was preempted.
      
      Change-Id: I6edd991032588588427ba2fe6c3d7668f7080e3d
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      90a9213b
  5. 20 Aug, 2018 2 commits
  6. 22 Jun, 2018 2 commits
  7. 21 Jun, 2018 3 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: Determine client EL from NS context's SCR_EL3 · 2ccfcb2e
      Jeenu Viswambharan authored
      
      
      Currently, the dispatcher reads from SCR_EL3 register directly to
      determine the EL of SDEI client. This is with the assumption that
      SCR_EL3 is not modified throughout. However, with RAS work flows, it's
      possible that SCR_EL3 register contains values corresponding to Secure
      world, and therefore EL determination can go wrong. To mitigate this,
      always read the register from the saved Non-secure context.
      
      Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      2ccfcb2e
    • 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
  8. 08 Jun, 2018 1 commit
  9. 27 Feb, 2018 1 commit
    • Jeenu Viswambharan's avatar
      SDEI: Pop dispatch context only after error checking · 8e3032f9
      Jeenu Viswambharan authored
      
      
      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: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      8e3032f9
  10. 20 Nov, 2017 1 commit
  11. 13 Nov, 2017 2 commits