Skip to content

GitLab

Switch branch/tag
  1. 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
  3. 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
  7. 22 Jun, 2018 2 commits
  9. 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
  11. 08 Jun, 2018 1 commit
  13. 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
  15. 20 Nov, 2017 1 commit
  17. 13 Nov, 2017 2 commits