Re: [PATCH v3] Documentation: Add section about CPU vulnerabilities for Spectre

[Jon Masters]

Hi Tim,

Nice writeup. A few suggestions inline.

On 6/17/19 3:11 PM, Tim Chen wrote:

> +In Spectre variant 2 attacks, the attacker can steer speculative indirect
> +branches in the victim to gadget code by poisoning the branch target
> +buffer of a CPU used for predicting indirect branch addresses. Such
> +poisoning could be done by indirect branching into existing code, with the
> +address offset of the indirect branch under the attacker's control. Since
> +the branch prediction hardware does not fully disambiguate branch address
> +and uses the offset for prediction, this could cause privileged code's
> +indirect branch to jump to a gadget code with the same offset.

Maybe mention "on impacted hardware" (implied).

> +One other variant 2 attack vector is for the attacker to poison the
> +return stack buffer (RSB) [13] to cause speculative RET execution to go
> +to an gadget.  An attacker's imbalanced CALL instructions might "poison"
> +entries in the return stack buffer which are later consumed by a victim's
> +RET instruction.  This attack can be mitigated by flushing the return
> +stack buffer on context switch, or VM exit.

Maybe replace CALL and RET with generic equivalents or label as x86
examples.

> +   For kernel code that has been identified where data pointers could
> +   potentially be influenced for Spectre attacks, new "nospec" accessor
> +   macros are used to prevent speculative loading of data.

Maybe explain that nospec (speculative clamping) relies on the absence
of value prediction in the masking (in current hardware). It may NOT
always be a safe approach in future hardware, where Spectre-v1 attacks
are likely to persist but hardware may speculate about the mask value.

> +   On x86, a user process can protect itself against Spectre variant
> +   2 attacks by using the prctl() syscall to disable indirect branch
> +   speculation for itself.

This is not x86 specific. The same prctl is wired up elsewhere also.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop