Have a Q. Found the following artic which although is for a different CVS vulnerability more generally describes ways to read proc settings directly to verify mitigations installed
https://www.suse.com/support/kb/doc/?add=&id=7022937&title=Security+Vulnerability:+Spectre+Variant+4+(Speculative+Store+Bypass)+aka+CVE-2018-3639. Was wondering whether there is an article similar to the one referenced by "@PGnet Dev" that's a good jumping off point for other virtualization, specifically KVM? Thx, Tony On Mon, Apr 15, 2019 at 9:35 AM Dario Faggioli <[email protected]> wrote: > > On Mon, 2019-04-15 at 07:17 -0700, PGNet Dev wrote: > > On 4/15/19 3:08 AM, Dario Faggioli wrote: > > > > > > > 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? > > > Yes. > > > 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 ... > > > I still haven't time to download and check the code of the checker, but > point is this: > - exploiting L1TF, it may be possible to read the host physical RAM > from inside a VM. This means malicious code running inside a VM can > read the memory of other applications inside the same VM, of other > VMs and also of the hypervisor. > It is not entirely trivial, even without mitigations applied, but > it's possible, and proofs of contept do exist; > - for Xen PV guests, if the guest has "PTE Inversion" and Xen has > pv-l1tf enabled, the problem is fully mitigated; > - for Xen HVM guests or KVM guests, on system without hyperthreading > (or with hyperthreading properly disabled), if L1D flush is supported > (by hardware and hypervisor) and enabled, the problem is fully > mitigated; > - for Xen HVM guests or KVM guests, on system with hypetrheading, > the problem can't be fully mitigated. > > So, the tool reporting "STATUS: UNKNOWN" for your dom0 was wrong, > because you seem to have all the pieces in place for PV guests to not > be vulnerable. > > For KVM guests and Xen HVM guests, can you paste the full output of the > section "CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'" ? > > > > > 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? > > > The existence of that line in 'Hardware Feature' is evidence that your > hardware is (quite possibly thanks to a microcode update) capable of > doing L1D flushes, which can be used by the hypervisor as part of the > mitigations for L1TF. > > In Xen, the fact that you are specifying this: > > GRUB_CMDLINE_XEN="...spec-ctrl=...,l1d-flush=true ..." > > And more specifically the fact that you have this in the logs: > > (XEN) Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD+, Other: IBPB > L1D_FLUSH > > is evidence that, let's say, L1D_FLUSH is being use to L1TF, for HVM > guests. If you have hyperthreading disabled (e.g., from BIOS, as I see > you have "smt=true" on Xen cmd line), then it's a full and proper > mitigation. If (much more likely, I think) you have hyperthreading > enabled, that's only a partial mitigation. > > > > 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 ... > > > Sure, I understand. Our policy, for this things, is to stay much rather > on the secure side (more than others, e.g., we use IBRS on SkyLake and > later hardware, which is something others call paranoid and just go > with Retpoline). > > On this L1TF-vs-hyperthreading thing, well, both the risk assessment > and the performance impact are so much use case and workload dependant > that we need the user to step in. > > > > 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 ... > > > Exactly. > > Regards > -- > Dario Faggioli, Ph.D > http://about.me/dario.faggioli > Virtualization Software Engineer > SUSE Labs, SUSE https://www.suse.com/ > ------------------------------------------------------------------- > <<This happens because _I_ choose it to happen!>> (Raistlin Majere) > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
