Re: How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?

On 4/15/19 3:08 AM, Dario Faggioli wrote:
>>
>> Not sure yet why I'm seeing UNKNOWN here,
>>
> I haven't checked the source code but that's, most likely, because the
> checked tries to figure out whether the Linux kernel, on top of the
> hardware where it's running, has the capability to --let's say-- issue
> the L1D-Flush instructions, without taking into account the fact that
> you may be running inside a Xen (PV) guest.
> 
> In fact, if you run this check from within a Xen dom0 (which you are,
> aren't you?),

Yes, I am exec'ing this at the Dom0 shell.

> you're inside a PV-guest, on top of Xen, and a PV-guest
> can't do the L1D flush (basically because that would be pointless for
> it).

Which, IIUC, would be the case for ANY Xen PV-guest as well?

I do note that, cursorily testing the checker in a (hosted elsewhere) 
KVM guest, I see:

   STATUS:  NOT VULNERABLE  (this system is not running an hypervisor)

which is a different result, though still in a Hypervisor-host's VM 
guest ...

> So, this is all technically correct.
 >
>> 	(2) Hardware-backed L1D flush supported:  NO
>>
> Again, this is correct. As far as the dom0 PV kernel knows and see, the
> hardware is not capable of that. That's because the view of the
> hardware it has is filtered by Xen, and Xen let it believe (and that's
> on purpose) that this is the situation.
> 
>> even though
>>
>> 	(XEN) [00000028c19f6e50]   Hardware features: IBRS/IBPB STIBP
>> L1D_FLUSH SSBD
>>
> Exactly, and this is what is important to have in the logs and to
> check, in order to know whether you have the L1TF mitigations in place.

To be clear, is the *existence* of "L1D_FLUSH" in that 'Hardware 
Features:' log line evidence that the feature is, in fact, *in use* as a 
Spectre mitigation?

>> What's missing in my config to mitigate/remove the CVE-2018-3646
>> vulnerability?
>>
> There's nothing you're missing, as far as I can tell. What the problem
> seems to be, is that spectre-and-meltdown-checker.sh does not treat the
> case of this check being made within a Xen (PV) guest properly.
> 
> I'll check whether this is actually the case, and I'll to see about
> fixing that, as soon as I find a minute.

Thanks.

> Oh, BTW, you know this already, but let me also add this: if you are
> running only PV guests, with the settings you've shown you are using,
> you are indeed safe against L1TF.

Yep.  And I do ... _mostly_.  On occassion, I do run HVM guest, so 
fussing with this.

Generally, I'd like to get a handle on all the mitigations, in all use 
cases, and then make any decisions about performance-vs-security ...

> If you are running HVM guests too, the only way to be totally and
> absolutely safe is, for now, to disable hyperthreading (and that's the
> case for KVM too, FWIW).

Sure.  With the available 'compromise' of leaving it enabled, if one 
makes the call that the host/guest are under sufficiently secure control ...