MIPS: mitigations for side channel vulnerabilities on speculative execution CPUs

Home Forums MIPS Insider MIPS FAQ MIPS: mitigations for side channel vulnerabilities on speculative execution CPUs

This topic contains 0 replies, has 1 voice, and was last updated by  MIPS Marketing 2 years, 9 months ago.

Viewing 1 post (of 1 total)
  • Author
  • #89093

    MIPS Marketing

    This topic is about the recent Spectre and Meltdown security vulnerabilities identified for some speculative execution CPUs. For an overview of this issue and which MIPS processor cores are affected by the cache timing side channel mechanisms employed to expose the vulnerabilities, please see our blog post on the topic. The following discusses potential mitigations to this issue.

    For the affected MIPS processors, there are several independent mitigation alternatives that can be used to avoid the vulnerabilities. An overview of these mitigation approaches are described at a high level here, starting with the most specific mitigations then becoming more general. The performance impact will depend on the method used and the actual workload. Please contact us, as described in further information below, if further help is needed to implement one of these mitigations.

    1. Insert an EHB barrier instruction before data load(s) that should not be speculated. All instructions prior to the barrier graduate before any subsequent instructions can be executed, and therefore avoids the possibility of a speculative load following the barrier. This technique is useful when specific loads can be identified that cannot tolerate speculative operation.
    2. Insert a fetch barrier instruction (e.g., JR.HB or JALR.HB) as a jump to reach any code that cannot tolerate speculation. These barrier instructions require all previous instructions and the barrier itself to graduate before any subsequent instructions are fetched. This technique is useful to avoid either variant 1 or variant 2 of Spectre.
    3. Disable speculation on all memory regions or on particular data regions that cannot tolerate speculation, using the Coprocessor 0 Memory Accessibility Attribute Registers (MAAR). This technique is useful if particular memory regions can be identified that cannot tolerate data speculation, but the individual loads themselves are not easily identified.
      • The MAAR registers whether instruction or data references can “speculatively” access a memory region within the address bounds specified. In this case, “speculation” allows an otherwise cacheable memory access to proceed external to the processor core before a data reference is ready to graduate, or before a fetch is known to be required.
      • At power up, all memory regions are defaulted to be non-speculative. A typical operating system like Linux will generally set most cacheable regions to allow speculation.
      • Disabling data speculation on appropriate memory regions with the MAAR settings can mitigate all flavors of the disclosed cache side channel attacks, without the need to insert EHB barrier instructions or disable fetch prediction.
    4. Disable instruction fetch prediction structures. The Coprocessor 0 Device Configuration registers contain fields that allow various fetch prediction structures to be disabled altogether. This technique is useful to preclude fetch prediction and consequently speculative data loads in the shadow of the fetch prediction. This technique may be relevant if specific fetch prediction structures are believed to be vulnerable, especially for variant 2 of Spectre. There are separate fields for these fetch structures (for all fields a ‘0’ enables and a ‘1’ disables that structure):
      • Config7.BP disables conditional branch prediction (e.g., BEQ, BGEZ, BGTZ, etc)
      • Config6.JRCD disables the JR cache for register indirect jumps (e.g., JALR / JR rn, n!=31)
      • Config7.RPS disables the return prediction stack for subroutine calls and returns (e.g., JALR / JR r31)
Viewing 1 post (of 1 total)

Forums are currently locked.