Skip to content

GitLab

Switch branch/tag
  1. 06 Dec, 2018 3 commits
  3. 05 Dec, 2018 4 commits
  5. 04 Dec, 2018 14 commits
  7. 03 Dec, 2018 2 commits
  9. 30 Nov, 2018 1 commit
  11. 29 Nov, 2018 5 commits
  13. 28 Nov, 2018 1 commit
  15. 27 Nov, 2018 6 commits
  17. 26 Nov, 2018 4 commits
    • Jeenu Viswambharan's avatar
      docs: Add RAS framework documentation · 63eb2410
      Jeenu Viswambharan authored 
      

Change-Id: Ibf2b21b12ebc0af5815fc6643532a3be9100bf02
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      63eb2410
    • Joel Hutton's avatar
      Initial Spectre V1 mitigations (CVE-2017-5753). · 9edd8912
      Joel Hutton authored 
      Initial Spectre Variant 1 mitigations (CVE-2017-5753).
A potential speculative data leak was found in PSCI code, this depends
on a non-robust implementation of the `plat_get_core_pos_by_mpidr()`
function. This is considered very low-risk. This patch adds a macro to
mitigate this. Note not all code paths could be analyzed with current
tools.

Add a macro which makes a variable 'speculation safe', using the
 __builtin_speculation_safe_value function of GCC and llvm. This will be
available in GCC 9, and is planned for llvm, but is not currently in
mainline GCC or llvm. In order to implement this mitigation the compiler
must support this builtin. Support is indicated by the
__HAVE_SPECULATION_SAFE_VALUE flag.

The -mtrack-speculation option maintains a 'tracker' register, which
determines if the processor is in false speculation at any point. This
adds instructions and increases code size, but avoids the performance
impact of a hard barrier.

Without the -mtrack-speculation option, __builtin_speculation_safe_value
expands to a

    ISB
    DSB SY

sequence after a conditional branch, before the
speculation safe variable is used. With -mtrack-speculation a

    CSEL tracker, tracker, XZR, [cond];
    AND safeval,tracker;
    CSDB

sequence is added instead, clearing the vulnerable variable by
AND'ing it with the tracker register, which is zero during speculative
execution. [cond] are the status flags which will only be true during
speculative execution. For more information on
__builtin_speculation_safe_value and the -mtrack-speculation option see
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/compiler-support-for-mitigations



The -mtracking option was not added, as the performance impact of the
mitigation is low, and there is only one occurence.

Change-Id: Ic9e66d1f4a5155e42e3e4055594974c230bfba3c
Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9edd8912
    • Jeenu Viswambharan's avatar
      docs: Add Exception Handling Framework documentation · e31d76fd
      Jeenu Viswambharan authored 
      

Change-Id: I77d38758d18ba6dda1652b1b1e644fbfb14386cc
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      e31d76fd
    • 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