April 2019 - openSUSE Security - openSUSE Mailing Lists

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

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

1 0

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

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

1 0

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

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

1 0

[opensuse-security] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

Following along at CVE-2018-3646 Common Vulnerabilities and Exposures https://www.suse.com/security/cve/CVE-2018-3646/ & Security Vulnerability: Spectre Variant 4 (Speculative Store Bypass) aka CVE-2018-3639. https://www.suse.com/support/kb/doc/?id=7022937 piecing together a number of other posts, and noting https://lists.opensuse.org/opensuse-security-announce/2018-12/msg00073.html An update that solves 9 vulnerabilities and has four fixes is now available. This update for xen fixes the following issues: Update to Xen 4.10.2 bug fix release (bsc#1027519). ... - CVE-2018-3646: Mitigations for VMM aspects of L1 Terminal Fault (XSA-273) (bsc#1091107) which references, Bug 1091107 - VUL-0: CVE-2018-3646: xen: L1 Terminal Fault -VMM (XSA-273) https://bugzilla.suse.com/show_bug.cgi?id=1091107 ==> Status: RESOLVED FIXED on uname -rm 5.0.7-lp150.5.g012b5f1-default x86_64 lsb_release -rd Description: openSUSE Leap 15.0 Release: 15.0 grep "model name" /proc/cpuinfo | head -n 1 model name : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz booting a Xen Dom0 host, dmesg | grep -i "xen version" [ 1.188399] Xen version: 4.12.0_09-lp150.640 (preserve-AD) In my grub cfg, GRUB_CMDLINE_LINUX_XEN_REPLACE="... spectre_v2=retpoline,generic spec_store_bypass_disable=on ..." GRUB_CMDLINE_XEN="... spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true ucode=scan ..." Updating microcode in Xen environments https://www.suse.com/support/kb/doc/?id=7022546 after grub re-config & mkinitrd, then reboot, per Updating microcode in Xen environments https://www.suse.com/support/kb/doc/?id=7022546 verifying, egrep "family|model|stepping" /proc/cpuinfo -m 4 cpu family : 6 model : 60 model name : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz stepping : 3 in hex, [cpu family]-[model]-[stepping] === 06-3C-03 rpm -qa | grep -i ucode-intel ucode-intel-20190312-lp150.3.1.x86_64 rpm -ql ucode-intel | grep -i 06-3C-03 /lib/firmware/intel-ucode/06-3c-03 lsinitrd /boot/initrd-5.0.7-lp150.5.g012b5f1-default Image: /boot/initrd-5.0.7-lp150.5.g012b5f1-default: 18M ======================================================================== Early CPIO image ======================================================================== drwxr-xr-x 3 root root 0 Apr 14 20:15 . -rw-r--r-- 1 root root 2 Apr 14 20:15 early_cpio drwxr-xr-x 3 root root 0 Apr 14 20:15 kernel drwxr-xr-x 3 root root 0 Apr 14 20:15 kernel/x86 drwxr-xr-x 2 root root 0 Apr 14 20:15 kernel/x86/microcode -rw-r--r-- 1 root root 23552 Apr 14 20:15 kernel/x86/microcode/GenuineIntel.bin ======================================================================== Version: dracut-044-lp150.14.27.1 grep -m1 microcode /proc/cpuinfo microcode : 0x25 in serial log (XEN) [00000027c847dc37] Xen version 4.12.0_09-lp150.640 (abuild(a)suse.de) (gcc (SUSE Linux) 8.3.1 20190305 [gcc-8-branch revi sion 269383]) debug=n Thu Apr 11 22:29:39 UTC 2019 (XEN) [00000027cb3e1267] Latest ChangeSet: (XEN) [00000027cbff3231] Bootloader: EFI (XEN) [00000027ccb72e3d] Command line: dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcpus=4 spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 reboot=acpi ucode=scan log_buf_len=16M loglvl=warning guest_loglvl=none/warning noreboot=false iommu=verbose ... (XEN) [00000028c099c50b] Speculative mitigation facilities: (XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD (XEN) [00000028c2f57689] Compiled-in support: INDIRECT_THUNK SHADOW_PAGING (XEN) [00000028c445abaf] Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD+, Other: IBPB L1D_FLUSH (XEN) [00000028c61da08b] L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe address 8000000000 (XEN) [00000028c7f67494] Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU (XEN) [00000028c94630dc] Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU (XEN) [00000028ca92b21c] XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID) (XEN) [00000028cc1cfa07] PV L1TF shadowing: Dom0 enabled, DomU enabled then, cd /sys/devices/system/cpu/vulnerabilities/ for f in $(ls); do echo -e "\n$f"; cat $f; done l1tf Mitigation: PTE Inversion meltdown Unknown (XEN PV detected, hypervisor mitigation required) spec_store_bypass Mitigation: Speculative Store Bypass disabled spectre_v1 Mitigation: __user pointer sanitization spectre_v2 Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling BUT, checking with spectre-meltdown-checker.sh still returns "STATUS: VULNERABLE", ... CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: * This system is a host running an hypervisor: YES * 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: YES > STATUS: VULNERABLE (disable EPT or enabled L1D flushing to mitigate the vulnerability) ... Since I'm on Xen, 'Mitigation 1' isn't an option. Two things catch my attention: (1) L1D flush enabled: UNKNOWN (unrecognized mode) Not sure yet why I'm seeing UNKNOWN here, & (2) Hardware-backed L1D flush supported: NO even though (XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD ^^^^^^^^^ What's missing in my config to mitigate/remove the CVE-2018-3646 vulnerability? -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 2