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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

PGNet Dev-2
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 ([hidden email]) (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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Tony Su
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 <[hidden email]> wrote:

>
> 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 ([hidden email]) (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: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

PGNet Dev-2
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-update-guidance.pdf

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-Data-File?product=75052)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

PGNet Dev-2
In reply to this post by PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

PGNet Dev-2
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: [hidden email]
To contact the owner, e-mail: [hidden email]