[Xen-devel] (partial) Spectre v2 mitigation without on Skylake IBRS

["Jan Beulich" <JBeulich@xxxxxxxx>]

All,

if running PV Linux on older Xen (4.5 and earlier) is relevant, it may be
necessary to use a mechanism other than IBRS to mitigate Spectre v2
on Skylake. That is because the new MSR value can't be migrated
prior to migration v2. Of course one option would be to retrofit some
mechanism into newer Xen versions that makes them accept whatever
extension to e.g. struct hvm_hw_cpu one might want to invent for
the older Xen versions. But that doesn't seem very desirable.

Hence I've been considering a kernel side approach as alternative.
To recap, iirc the reason retpoline isn't enough on Skylake is that RET
may consult the BTB upon RSB underflow. All other aspects can be
dealt with using the existing combination of retpoline and RSB stuffing.
The idea is to use a retpoline for RET as well:

RET_repoline:
        call    2f
1:
        lfence
        jmp     1b
2:
        lea     8(%rsp), %rsp
        ret

(32-bit version would be quite similar). This would mostly avoid the
risk of RSB underflows; the case of async events - SMI being the
worst - in the middle of the thunk of course wouldn't be possible to
deal with, but I think that might be acceptable, as an attacker can't
control their arrival.

Obviously this isn't going to be easy without compiler support, yet
I'm unconvinced we could talk the compiler folks into adding yet
another option to support such a mode, the more that it would be
a partial mitigation only. Hence the other way of achieving this
would need considering - inject a "ret" macro into the assembler
output produced by the compiler, converting every ret to a branch
to the thunk. This, in turn, may be a hard sell to the x86
maintainers. Otoh, having done such for other purposes already
(experimental only, i.e. never posted publicly anywhere) I think I
have all the building pieces ready for re-use.

Opinions appreciated,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel