Re: x86: AMD Zen1 Div leakage

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.08.2023 22:29, Andrew Cooper wrote:
> This popped up with insufficient time to organise a response before the
> pile of fixes yesterday.
> 
> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7007.html
> 
> Per my current understanding:
> 
> * There is a single integer divider in a Zen1 pipeline.  When SMT is
> active, it services uops from both threads.
> 
> * It latches the result of the last calculation performed, but forwards
> said result transiently in the case of #DE (i.e. meltdown-like).
> 
> If this is accurate, then there's a nice covert channel between the two
> threads, where they can communicate by issuing specific divides, without
> ever leaving userspace.  (It's easy to hide a #DE in the shadow of some
> other misprediction, and not suffer a real divide exception.)
> 
> But, div isn't a serialising uop, so the advice of "don't divide
> secrets" is tantamount to useless.  Transient execution can pick up a
> div uop from any misaligned instruction, and end up caculating on
> arbitrary operands.
> 
> 
> In SMT=0 cases, we can scrub in Xen by executing 0 / 1, and would need
> to go in the same place as VERW on Intel (i.e. very late in the
> return-to-guest path).

Executing 1 / 1 may be yet slightly cheaper, unless there's special
casing of 0 as the dividend in hardware (in which case I would wonder
whether then the result would actually be latched).

Is putting this on the exit path going to be enough? Without also
scrubbing on entry what was latched, speculation inside Xen could be
"driven" (to a limited degree) from the outside (i.e. spectre-like).

> In SMT=1 cases, I can't see any fix.  It's very much like L1TF/MDS, and
> cooperating threads can snatch data a cycle or two after it was placed
> in the channel.

I agree, ...

> As yet, I haven't started any patches to this effect, but it would be
> nice to have more clarity from AMD first.

... provided nothing new turns up in what exactly the issue is. The Linux
commit that attempts to address this deals with this inside the #DE
handler, apparently assuming the issue can only occur when #DE is
actually raised. Your (and my limited) understanding go in a different
direction, though.

Jan