[opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
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@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-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
IMO
You first need to provide source for your spectre-meltdown checker,
like any app of this type it's important to understand how it works
and its limitations, possibly leading to false positives or
ineffectiveness.
Personally, I prefer the following It was one of the first tools
available and the author seems to be reasonably conscientious about
keeping his tool up to date.. It also doesn't hurt that it's open
source and he describes what his tool does.
https://github.com/speed47/spectre-meltdown-checker
As for Spectre and Meltdown specifically...
It's my understanding that openSUSE installs microcode patches during
every bootup including Spectre and Meltdown mitigations. I don't know
if simply booting an updated machine is sufficient to address the
specific vulnerability you want to patch but in part that is what the
vulnerability checker is supposed to tell you.
Note also that regarding Meltdown and Spectre (more importantly the
latter), the best first step to address these vulnerabilities is to be
using a CPU shipped sometime between February 2018 and today, only
those processors can be patched "properly." Once patched, it's my
understanding that Meltdown and Spectre just won't work. Any earlier
CPU cannot be properly patched, the only thing that can be done is to
mitigate by blocking attack vectors as they are discovered.
HTH and that is the best of my understanding,
Tony
On Sun, Apr 14, 2019 at 9:02 PM PGNet Dev
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@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-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On 4/14/19 9:28 PM, Tony Su wrote:
You first need to provide source for your spectre-meltdown checker,
this is an Opensuse pkg, sourced from the Opensuse security repo, https://build.opensuse.org/package/show/security/spectre-meltdown-checker referenced re: Spectre mitigation, e.g., here: https://lists.opensuse.org/opensuse-factory/2019-04/msg00169.html
It's my understanding that openSUSE installs microcode patches during every bootup including Spectre and Meltdown mitigations.
It depends on kernel/hypervisor configuration & available/installed microcode That's the point of my post -- the correct configuration.
only those processors can be patched "properly."
As mentioned, my CPU is Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz Per intel's "microcode update guidance" https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-upd... the suite of Haswell Xeon v3 Processors, including: E3-1220V3, E3-1225V3, E3-1230LV3, E3-1230V3, E3-1240V3, E3-1245V3, E3-1270V3, E3-1275LV3, E3-1275V3, E3-1280V3, E3-1285LV3, E3-1285LV3, E3-1285V3 ^^^^^^^^^ are supported in production updates, with the latest available firmware data files @: https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Da...) -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Sun, 2019-04-14 at 21:28 -0700, Tony Su wrote:
Personally, I prefer the following It was one of the first tools available and the author seems to be reasonably conscientious about keeping his tool up to date.. It also doesn't hurt that it's open source and he describes what his tool does.
I believe that is exactly the one we package, and that PGNet is using.
See, e.g.:
https://build.opensuse.org/package/show/security/spectre-meltdown-checker
https://build.opensuse.org/package/view_file/security/spectre-meltdown-check...
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
Hi, On Sun, 2019-04-14 at 21:02 -0700, PGNet Dev wrote:
BUT, checking with
spectre-meltdown-checker.sh
still returns "STATUS: VULNERABLE",
[...]
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,
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?), 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). 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.
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.
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.
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).
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
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-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
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/
-------------------------------------------------------------------
<
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-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Mon, 2019-04-15 at 09:59 -0700, PGNet Dev wrote:
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.
Ah, thanks. :-)
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.
As we were saying, it's rather hard to tell from the outside whether it's balanced or overkill. It's pretty much what we do by default, which might be seen as a good sign, I guess.
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
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. :-)
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
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-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
[Sorry for replying a little late] On Mon, 2019-04-15 at 13:41 -0700, PGNet Dev wrote:
*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
I think you're talking about IBRS. I mean, we do enable IBPB, but that's what pretty much everyone does, I think. In fact, on openSUSE kernel-default, Spectre-v2 is mitigated like this (on post-SkyLake hardware): Mitigation: Indirect Branch Restricted Speculation, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling with kernel-vanilla, like this: Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling The impact, as said, varies, and it may not be *always* 20%. But yes, it's non-negligible, for most workloads
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.
Yes, makes sense.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
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
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/ ------------------------------------------------------------------- <
> (Raistlin Majere)
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Mon, 2019-04-15 at 10:12 -0700, Tony Su wrote:
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
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?
I'm not sure I have understood what you are after.
Each one of these things being --although all somewhat related--
different vulnerabilities, came out at different times, each has its
own piece of documentation (or, often, more than one!).
L1TF is the one which, it can be stated, is the most related to
virtualization, and SUSE docs for it is here (not sure this was liked
already):
https://www.suse.com/support/kb/doc/?id=7023077
The most authoritative source of info for KVM would be, IMO, the kernel
documentation:
https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
For Xen, I personally think the XSA is particularly well done:
https://xenbits.xen.org/xsa/advisory-273.html
But again, I'm not sure it was things like these you were actually
looking for...
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
After re-evaluating the various Spectre vulnerabilities mainly using
the meltdown-spectre checker script as my initial guide, there appears
to be a variety of somewhat different vulnerabilities of which L1TF is
not the only one affecting virtualization but very significant.
Because each vulnerability is so different, it should not be assumed
that there is any silver bullet that can address all vulnerabilities,
each vulnerability has to be addressed individually and again... the
meltdown-spectre checker script is a good place to start since the
github page summarizes each vulnerability and required mitigations.
So, for instance I may be incorrect but it looks like retpoline has
nothing to do with the L1TF vulnerability.
I find the SUSE kb pages for these vulnerabilities and recommended
mitigations extremely hard to read due to formatting, and it may not
be clear in some text whether a list of settings are simply options or
defaults. Compare for instance the SUSE CVE-2018-3639 page with the
roughly corresponding Linux.org page which looks to me extensive and
likely more complete, better describing the EPT and hyperthreading
options. The linux.org page leads by describing each affected
component and settings, and ends with numerous mitigation options and
their effectiveness.
https://www.suse.com/support/kb/doc/?add=&id=7022937&title=Security+Vulnerability:+Spectre+Variant+4+(Speculative+Store+Bypass)+aka+CVE-2018-3639.
https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
I haven't checked completely, but I think that the meltdown-spectre
checker script reads the various /sys/ values among other things
automatically and reports their values, so one doesn't have to check
those values manually and individually.
Only remaining question is whether an openSUSE install and updates
should automatically install recommended mitigations by default
depending on whether it's detected to be running on bare metal or
virtualized, and then the User option should then be to disable
mitigations.
Tony
On Mon, Apr 15, 2019 at 10:58 AM Dario Faggioli
On Mon, 2019-04-15 at 10:12 -0700, Tony Su wrote:
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
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?
I'm not sure I have understood what you are after.
Each one of these things being --although all somewhat related-- different vulnerabilities, came out at different times, each has its own piece of documentation (or, often, more than one!).
L1TF is the one which, it can be stated, is the most related to virtualization, and SUSE docs for it is here (not sure this was liked already):
https://www.suse.com/support/kb/doc/?id=7023077
The most authoritative source of info for KVM would be, IMO, the kernel documentation: https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
For Xen, I personally think the XSA is particularly well done: https://xenbits.xen.org/xsa/advisory-273.html
But again, I'm not sure it was things like these you were actually looking for...
Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <
> (Raistlin Majere)
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
On Tue, 2019-04-16 at 11:41 -0700, Tony Su wrote:
After re-evaluating the various Spectre vulnerabilities mainly using the meltdown-spectre checker script as my initial guide, there appears to be a variety of somewhat different vulnerabilities of which L1TF is not the only one affecting virtualization but very significant.
Well, absolutely. And I never intended to say it was... only that is one of the most relevant to virtualization, and that it is still partially unresolved (without disabling hyperthreading, of course). E.g., this is about Spectre-&-Meltdown on virtualization, and L1TF isn't even mentioned (as it hasn't even been discovered, when that page was written :-D): https://www.suse.com/support/kb/doc/?id=7022514
Because each vulnerability is so different, it should not be assumed that there is any silver bullet that can address all vulnerabilities, each vulnerability has to be addressed individually and again... the meltdown-spectre checker script is a good place to start since the github page summarizes each vulnerability and required mitigations.
It's a great project, I agree. It's got its issues, but that's the case for all pieces of software out there.
So, for instance I may be incorrect but it looks like retpoline has nothing to do with the L1TF vulnerability.
Not at all, no.
I find the SUSE kb pages for these vulnerabilities and recommended mitigations extremely hard to read due to formatting, and it may not be clear in some text whether a list of settings are simply options or defaults.
Mmm... yes, maybe what the default setting is, is something that could be missing in there. However, bear in mind that the default could be "dynamically figure out the best mitigation strategy", e.g., basing on what kind of hardware you're running on. Therefore, even if you know what the default is, and you didn't touch anything, it's always worth checking what was picked as a solution.
Compare for instance the SUSE CVE-2018-3639 page with the roughly corresponding Linux.org page which looks to me extensive and likely more complete, better describing the EPT and hyperthreading options. The linux.org page leads by describing each affected component and settings, and ends with numerous mitigation options and their effectiveness.
https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html
Wait... if we're back talking about L1TF, the SUSE pages about it are these: https://www.suse.com/support/kb/doc/?id=7023077 https://www.suse.com/support/kb/doc/?id=7023078 not the one liked above. And, if we want to be fair, the scope, the goal and the target audience, between those SUSE docs and kernel.org doc, are rather different. But yeah, I guess we could have done better... We have in the works some kind of more complete piece of documentation, that can act as a single point of reference for the issue. I'll post the link on this list when it's finished and released (it may take a little).
Only remaining question is whether an openSUSE install and updates should automatically install recommended mitigations by default depending on whether it's detected to be running on bare metal or virtualized, and then the User option should then be to disable mitigations.
Linux kernel does that already, so it's like that for any distro,
basically. What a distribution can do is change this default behavior,
if wanted, and SUSE and openSUSE do that (in order to make things
properly and really secure on SkyLake and later Intel hardware, against
Spectre-v2).
Basically, if you don't touch the default settings (and if you also
took care of the hardware side, by updating BIOS/microcode), you're
secure. If you want to disable (or change the strategy in use) some,
you need to act, e.g., on the kernel and/or hypervisor boot command
line.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
On Mon, 2019-04-15 at 07:17 -0700, PGNet Dev wrote:
On 4/15/19 3:08 AM, Dario Faggioli wrote:
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.
So, I finally gave a look at the spectre-meltdown-checker.sh source.
IMO, figuring out whether or not we're running on a system which we can
call "an hypervisor", is kind of broken, for both Xen and KVM.
This affects the meaningfulness of what the tool reports about L1TF
quite a bit.
I had a go at fixing a few things, mostly for KVM, though. I have a
branch here:
https://github.com/dfaggioli/spectre-meltdown-checker/tree/l1tf-host
(and I did send the pull request... let's see if the author likes my
changes).
I started to look at the Xen side of things, but then found this:
https://github.com/h0nIg/spectre-meltdown-checker/tree/xen
I still haven't tried, nor checked the patches thoroughly, but I'll
give it a look and see if we they're fine (and, probably, base any
future work on at least some of them).
But that won't happen before the end of next week.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<
Dario,
Thank you very much for your comments, they're clear, clarifying and essential.
Tony
On Fri, Apr 19, 2019 at 10:26 AM Dario Faggioli
On Mon, 2019-04-15 at 07:17 -0700, PGNet Dev wrote:
On 4/15/19 3:08 AM, Dario Faggioli wrote:
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.
So, I finally gave a look at the spectre-meltdown-checker.sh source.
IMO, figuring out whether or not we're running on a system which we can call "an hypervisor", is kind of broken, for both Xen and KVM.
This affects the meaningfulness of what the tool reports about L1TF quite a bit.
I had a go at fixing a few things, mostly for KVM, though. I have a branch here: https://github.com/dfaggioli/spectre-meltdown-checker/tree/l1tf-host
(and I did send the pull request... let's see if the author likes my changes).
I started to look at the Xen side of things, but then found this: https://github.com/h0nIg/spectre-meltdown-checker/tree/xen
I still haven't tried, nor checked the patches thoroughly, but I'll give it a look and see if we they're fine (and, probably, base any future work on at least some of them).
But that won't happen before the end of next week.
Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <
> (Raistlin Majere)
-- To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org
participants (3)
-
Dario Faggioli -
PGNet Dev -
Tony Su