Commits on Jan 11, 2018

1. Workaround for CVE-2017-5715 on Cortex A57 and A72 …

   Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling
   and enabling the MMU.  To achieve this without performing any branch
   instruction, a per-cpu vbar is installed which executes the workaround
   and then branches off to the corresponding vector entry in the main
   vector table.  A side effect of this change is that the main vbar is
   configured before any reset handling.  This is to allow the per-cpu
   reset function to override the vbar setting.
   
   This workaround is enabled by default on the affected CPUs.
   
   Change-Id: I97788d38463a5840a410e3cea85ed297a1678265
   Signed-off-by: Dimitris Papastamos <[email protected]>

   Dimitris Papastamos committed Jan 11, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for f62ad32
   • Browse repository at this point

   Copy the full SHA

   f62ad32 View commit details

   Browse the repository at this point in the history

2. Workaround for CVE-2017-5715 on Cortex A73 and A75 …

   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: Dimitris Papastamos <[email protected]>

   Dimitris Papastamos committed Jan 11, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for a1781a2
   • Browse repository at this point

   Copy the full SHA

   a1781a2 View commit details

   Browse the repository at this point in the history

3. Use PFR0 to identify need for mitigation of CVE-2017-5915 …

   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: Dimitris Papastamos <[email protected]>

   Dimitris Papastamos committed Jan 11, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for 780edd8
   • Browse repository at this point

   Copy the full SHA

   780edd8 View commit details

   Browse the repository at this point in the history