On 4/15/19 10:49 AM, Dario Faggioli wrote:
> On Mon, 2019-04-15 at 09:59 -0700, PGNet Dev wrote:
> It's pretty much what we do by default, which might be seen as a good
> sign, I guess.
*Suse also enables "IBPB" by default. is that (still) correct?
Which I'd like to NOT take the purported ~20% performance hit for, and
believe I've correctly (?) DISabled with adding:
spectre_v2=retpoline,generic
to my grub config's kernel command line
> Well, not quite. :-/
>
> In fact, this is from inside a guest. In order for things to be 100%
> safe, hyperthreading should be disabled at the _host_ level, which is
> something that the guest can't know.
>
> Actually, the guest can't know for sure whether or not the underlying
> host it is running on has L1D flush supported and enabled either.
>
> So, I think it is calling it "NOT VULNERABLE" on the ground, e.g., that
> , as it says, "this system is not running an hypervisor". But that is
> going to be true for any VM, unless one is using nested virtualization.
>
> If that's the case, the whole 'Foreshadow-NG (VMM)' block appears to be
> rather bogous... but I really want to speak only after having checked
> the code. :-)
Understood.
Also, I *did* see a KVM host-side change (namely, an upgrade to a fully
patched Host) that switched the reporting of Variant 3a & 4
vulnerabilities from VULNERABLE ==> NOT VULNERABLE, in the guest.
Which I believe is expected.
--
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org
On 4/15/19 9:34 AM, Dario Faggioli wrote:
> 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.
That's really clear. And the 1st time I've read it all, so succinctly stated, in one place.
It would, IMO, be very helpful on a 'Spectre on *Suse' doc/wiki page.
atm, on this particular host, my Xen cmd line includes:
spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true
which may, or not, be overkill/risky; still need to do some reading up on the relative merits.
> 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'" ?
Don't have a Xen HVM up right at the moment.
For KVM guest (@ Linode, fwiw),
spectre-meltdown-checker.sh
...
CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface:
* This system is a host running an hypervisor: NO
* Mitigation 1 (KVM)
* EPT is disabled: N/A (the kvm_intel module is not loaded)
* Mitigation 2
* L1D flush is supported by kernel: YES (found flush_l1d in kernel image)
* L1D flush enabled: UNKNOWN (unrecognized mode)
* Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower)
* Hyper-Threading (SMT) is enabled: NO
> STATUS: NOT VULNERABLE (this system is not running an hypervisor)
> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK
IIUC from your comments above, the apparently *dis*abled SMT hyperthreading leads, in this case, to the mitigation STATUS ==> NOT VULNERABLE
--
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org
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 ...
--
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org