1. 11 Jan, 2018 3 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
      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. 29 Nov, 2017 1 commit
  3. 01 Jun, 2017 1 commit