[Qemu-devel] CVE-2017-5715: relevant qemu patches

[Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

Hello,

i've seen some vendors have updated qemu regarding meltdown / spectre.

f.e.:

 CVE-2017-5715: QEMU was updated to allow passing through new MSR and
     CPUID flags from the host VM to the CPU, to allow enabling/disabling
     branch prediction features in the Intel CPU. (bsc#1068032)

Can anybody point me to the relevant qemu patches?

Thanks!

Greets,
Stefan

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Alexandre DERUMIER]

>>Can anybody point me to the relevant qemu patches? 

I don't have find them yet.

Do you known if a vm using kvm64 cpu model is protected or not ?

----- Mail original -----
De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag>
À: "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Jeudi 4 Janvier 2018 07:27:01
Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches

Hello, 

i've seen some vendors have updated qemu regarding meltdown / spectre. 

f.e.: 

CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
CPUID flags from the host VM to the CPU, to allow enabling/disabling 
branch prediction features in the Intel CPU. (bsc#1068032) 

Can anybody point me to the relevant qemu patches? 

Thanks! 

Greets, 
Stefan 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Alexandre DERUMIER]

does somebody have a redhat account to see te content of: 

https://access.redhat.com/solutions/3307851
"Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products"

----- Mail original -----
De: "aderumier" <aderumier@odiso.com>
À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag>
Cc: "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Jeudi 4 Janvier 2018 08:24:34
Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

>>Can anybody point me to the relevant qemu patches? 

I don't have find them yet. 

Do you known if a vm using kvm64 cpu model is protected or not ? 

----- Mail original ----- 
De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
À: "qemu-devel" <qemu-devel@nongnu.org> 
Envoyé: Jeudi 4 Janvier 2018 07:27:01 
Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 

Hello, 

i've seen some vendors have updated qemu regarding meltdown / spectre. 

f.e.: 

CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
CPUID flags from the host VM to the CPU, to allow enabling/disabling 
branch prediction features in the Intel CPU. (bsc#1068032) 

Can anybody point me to the relevant qemu patches? 

Thanks! 

Greets, 
Stefan 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

Am 04.01.2018 um 08:27 schrieb Alexandre DERUMIER:
> does somebody have a redhat account to see te content of: 
> 
> https://access.redhat.com/solutions/3307851
> "Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products"

i don't have one but the content might be something like this:
https://www.suse.com/de-de/support/kb/doc/?id=7022512

So you need:
1.) intel / amd cpu microcode update
2.) qemu update to pass the new MSR and CPU flags from the microcode update
3.) host kernel update
4.) guest kernel update

The microcode update and the kernel update is publicly available but i'm
missing the qemu one.

Greets,
Stefan

> ----- Mail original -----
> De: "aderumier" <aderumier@odiso.com>
> À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag>
> Cc: "qemu-devel" <qemu-devel@nongnu.org>
> Envoyé: Jeudi 4 Janvier 2018 08:24:34
> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches
> 
>>> Can anybody point me to the relevant qemu patches? 
> 
> I don't have find them yet. 
> 
> Do you known if a vm using kvm64 cpu model is protected or not ? 
> 
> ----- Mail original ----- 
> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
> À: "qemu-devel" <qemu-devel@nongnu.org> 
> Envoyé: Jeudi 4 Janvier 2018 07:27:01 
> Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
> 
> Hello, 
> 
> i've seen some vendors have updated qemu regarding meltdown / spectre. 
> 
> f.e.: 
> 
> CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
> CPUID flags from the host VM to the CPU, to allow enabling/disabling 
> branch prediction features in the Intel CPU. (bsc#1068032) 
> 
> Can anybody point me to the relevant qemu patches? 
> 
> Thanks! 
> 
> Greets, 
> Stefan 
> 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Alexandre DERUMIER]

>>So you need: 
>>1.) intel / amd cpu microcode update 
>>2.) qemu update to pass the new MSR and CPU flags from the microcode update 
>>3.) host kernel update 
>>4.) guest kernel update 

are you sure we need to patch guest kernel if we are able to patch qemu ?
I have some pretty old guest (linux and windows)



If I understand, patching the host kernel, should avoid that a vm is reading memory of another vm.
(the most critical)


patching the guest kernel, to avoid that a process from the vm have access to memory of another process of same vm.


right ?



----- Mail original -----
De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag>
À: "aderumier" <aderumier@odiso.com>
Cc: "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Jeudi 4 Janvier 2018 09:17:41
Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

Am 04.01.2018 um 08:27 schrieb Alexandre DERUMIER: 
> does somebody have a redhat account to see te content of: 
> 
> https://access.redhat.com/solutions/3307851 
> "Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products" 

i don't have one but the content might be something like this: 
https://www.suse.com/de-de/support/kb/doc/?id=7022512 

So you need: 
1.) intel / amd cpu microcode update 
2.) qemu update to pass the new MSR and CPU flags from the microcode update 
3.) host kernel update 
4.) guest kernel update 

The microcode update and the kernel update is publicly available but i'm 
missing the qemu one. 

Greets, 
Stefan 

> ----- Mail original ----- 
> De: "aderumier" <aderumier@odiso.com> 
> À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
> Cc: "qemu-devel" <qemu-devel@nongnu.org> 
> Envoyé: Jeudi 4 Janvier 2018 08:24:34 
> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
> 
>>> Can anybody point me to the relevant qemu patches? 
> 
> I don't have find them yet. 
> 
> Do you known if a vm using kvm64 cpu model is protected or not ? 
> 
> ----- Mail original ----- 
> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
> À: "qemu-devel" <qemu-devel@nongnu.org> 
> Envoyé: Jeudi 4 Janvier 2018 07:27:01 
> Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
> 
> Hello, 
> 
> i've seen some vendors have updated qemu regarding meltdown / spectre. 
> 
> f.e.: 
> 
> CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
> CPUID flags from the host VM to the CPU, to allow enabling/disabling 
> branch prediction features in the Intel CPU. (bsc#1068032) 
> 
> Can anybody point me to the relevant qemu patches? 
> 
> Thanks! 
> 
> Greets, 
> Stefan 
> 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

Am 04.01.2018 um 09:35 schrieb Alexandre DERUMIER:
>>> So you need: 
>>> 1.) intel / amd cpu microcode update 
>>> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
>>> 3.) host kernel update 
>>> 4.) guest kernel update 
> 
> are you sure we need to patch guest kernel if we are able to patch qemu ?
>> I have some pretty old guest (linux and windows)
>
> If I understand, patching the host kernel, should avoid that a vm is reading memory of another vm.
> (the most critical)

Yes - this was just to complete the mitigation on all layers.

> 
> patching the guest kernel, to avoid that a process from the vm have access to memory of another process of same vm.
Yes.

Stefan

> 
> 
> 
> ----- Mail original -----
> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag>
> À: "aderumier" <aderumier@odiso.com>
> Cc: "qemu-devel" <qemu-devel@nongnu.org>
> Envoyé: Jeudi 4 Janvier 2018 09:17:41
> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches
> 
> Am 04.01.2018 um 08:27 schrieb Alexandre DERUMIER: 
>> does somebody have a redhat account to see te content of: 
>>
>> https://access.redhat.com/solutions/3307851 
>> "Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products" 
> 
> i don't have one but the content might be something like this: 
> https://www.suse.com/de-de/support/kb/doc/?id=7022512 
> 
> So you need: 
> 1.) intel / amd cpu microcode update 
> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
> 3.) host kernel update 
> 4.) guest kernel update 
> 
> The microcode update and the kernel update is publicly available but i'm 
> missing the qemu one. 
> 
> Greets, 
> Stefan 
> 
>> ----- Mail original ----- 
>> De: "aderumier" <aderumier@odiso.com> 
>> À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>> Cc: "qemu-devel" <qemu-devel@nongnu.org> 
>> Envoyé: Jeudi 4 Janvier 2018 08:24:34 
>> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>
>>>> Can anybody point me to the relevant qemu patches? 
>>
>> I don't have find them yet. 
>>
>> Do you known if a vm using kvm64 cpu model is protected or not ? 
>>
>> ----- Mail original ----- 
>> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>> À: "qemu-devel" <qemu-devel@nongnu.org> 
>> Envoyé: Jeudi 4 Janvier 2018 07:27:01 
>> Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>
>> Hello, 
>>
>> i've seen some vendors have updated qemu regarding meltdown / spectre. 
>>
>> f.e.: 
>>
>> CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
>> CPUID flags from the host VM to the CPU, to allow enabling/disabling 
>> branch prediction features in the Intel CPU. (bsc#1068032) 
>>
>> Can anybody point me to the relevant qemu patches? 
>>
>> Thanks! 
>>
>> Greets, 
>> Stefan 
>>
> 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

Nobody? Is this something they did on their own?

Stefan

Am 04.01.2018 um 07:27 schrieb Stefan Priebe - Profihost AG:
> Hello,
> 
> i've seen some vendors have updated qemu regarding meltdown / spectre.
> 
> f.e.:
> 
>  CVE-2017-5715: QEMU was updated to allow passing through new MSR and
>      CPUID flags from the host VM to the CPU, to allow enabling/disabling
>      branch prediction features in the Intel CPU. (bsc#1068032)
> 
> Can anybody point me to the relevant qemu patches?
> 
> Thanks!
> 
> Greets,
> Stefan
> 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Paolo Bonzini]

On 04/01/2018 09:35, Alexandre DERUMIER wrote:
>>> So you need: 
>>> 1.) intel / amd cpu microcode update 
>>> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
>>> 3.) host kernel update 
>>> 4.) guest kernel update 
> 
> are you sure we need to patch guest kernel if we are able to patch qemu ?

Patching the guest kernel is only required to protect the guest kernel
from guest usermode.

> If I understand, patching the host kernel, should avoid that a vm is reading memory of another vm.
> (the most critical)

Correct.

> patching the guest kernel, to avoid that a process from the vm have access to memory of another process of same vm.

Correct.

The QEMU updates are pretty boring, mostly taking care of new MSR and
CPUID flags (and adding new CPU models).

They are not needed to protect the guest from "Meltdown", only
"Spectre"---the former only needs a guest kernel update.  Also, to have
any effect, the guest kernels must also have "Spectre" patches which
aren't upstream yet for either KVM or the rest of Linux.  So the QEMU
patches are much less important than the kernel side.

>> https://access.redhat.com/solutions/3307851 
>> "Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products" 

It mostly repeats the contents of the RHEL document
https://access.redhat.com/security/vulnerabilities/speculativeexecution,
with some information specific to RHV.

Thanks,

Paolo

> i don't have one but the content might be something like this: 
> https://www.suse.com/de-de/support/kb/doc/?id=7022512 
> 
> So you need: 
> 1.) intel / amd cpu microcode update 
> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
> 3.) host kernel update 
> 4.) guest kernel update 
> 
> The microcode update and the kernel update is publicly available but i'm 
> missing the qemu one. 
> 
> Greets, 
> Stefan 
> 
>> ----- Mail original ----- 
>> De: "aderumier" <aderumier@odiso.com> 
>> À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>> Cc: "qemu-devel" <qemu-devel@nongnu.org> 
>> Envoyé: Jeudi 4 Janvier 2018 08:24:34 
>> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>
>>>> Can anybody point me to the relevant qemu patches? 
>>
>> I don't have find them yet. 
>>
>> Do you known if a vm using kvm64 cpu model is protected or not ? 
>>
>> ----- Mail original ----- 
>> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>> À: "qemu-devel" <qemu-devel@nongnu.org> 
>> Envoyé: Jeudi 4 Janvier 2018 07:27:01 
>> Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>
>> Hello, 
>>
>> i've seen some vendors have updated qemu regarding meltdown / spectre. 
>>
>> f.e.: 
>>
>> CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
>> CPUID flags from the host VM to the CPU, to allow enabling/disabling 
>> branch prediction features in the Intel CPU. (bsc#1068032) 
>>
>> Can anybody point me to the relevant qemu patches? 
>>
>> Thanks! 
>>
>> Greets, 
>> Stefan 
>>
> 
> 

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

attached the relevant patch for everybody who needs it.

Greets,
Stefan
Am 04.01.2018 um 16:53 schrieb Paolo Bonzini:
> On 04/01/2018 09:35, Alexandre DERUMIER wrote:
>>>> So you need: 
>>>> 1.) intel / amd cpu microcode update 
>>>> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
>>>> 3.) host kernel update 
>>>> 4.) guest kernel update 
>>
>> are you sure we need to patch guest kernel if we are able to patch qemu ?
> 
> Patching the guest kernel is only required to protect the guest kernel
> from guest usermode.
> 
>> If I understand, patching the host kernel, should avoid that a vm is reading memory of another vm.
>> (the most critical)
> 
> Correct.
> 
>> patching the guest kernel, to avoid that a process from the vm have access to memory of another process of same vm.
> 
> Correct.
> 
> The QEMU updates are pretty boring, mostly taking care of new MSR and
> CPUID flags (and adding new CPU models).
> 
> They are not needed to protect the guest from "Meltdown", only
> "Spectre"---the former only needs a guest kernel update.  Also, to have
> any effect, the guest kernels must also have "Spectre" patches which
> aren't upstream yet for either KVM or the rest of Linux.  So the QEMU
> patches are much less important than the kernel side.
> 
>>> https://access.redhat.com/solutions/3307851 
>>> "Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products" 
> 
> It mostly repeats the contents of the RHEL document
> https://access.redhat.com/security/vulnerabilities/speculativeexecution,
> with some information specific to RHV.
> 
> Thanks,
> 
> Paolo
> 
>> i don't have one but the content might be something like this: 
>> https://www.suse.com/de-de/support/kb/doc/?id=7022512 
>>
>> So you need: 
>> 1.) intel / amd cpu microcode update 
>> 2.) qemu update to pass the new MSR and CPU flags from the microcode update 
>> 3.) host kernel update 
>> 4.) guest kernel update 
>>
>> The microcode update and the kernel update is publicly available but i'm 
>> missing the qemu one. 
>>
>> Greets, 
>> Stefan 
>>
>>> ----- Mail original ----- 
>>> De: "aderumier" <aderumier@odiso.com> 
>>> À: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>>> Cc: "qemu-devel" <qemu-devel@nongnu.org> 
>>> Envoyé: Jeudi 4 Janvier 2018 08:24:34 
>>> Objet: Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>>
>>>>> Can anybody point me to the relevant qemu patches? 
>>>
>>> I don't have find them yet. 
>>>
>>> Do you known if a vm using kvm64 cpu model is protected or not ? 
>>>
>>> ----- Mail original ----- 
>>> De: "Stefan Priebe, Profihost AG" <s.priebe@profihost.ag> 
>>> À: "qemu-devel" <qemu-devel@nongnu.org> 
>>> Envoyé: Jeudi 4 Janvier 2018 07:27:01 
>>> Objet: [Qemu-devel] CVE-2017-5715: relevant qemu patches 
>>>
>>> Hello, 
>>>
>>> i've seen some vendors have updated qemu regarding meltdown / spectre. 
>>>
>>> f.e.: 
>>>
>>> CVE-2017-5715: QEMU was updated to allow passing through new MSR and 
>>> CPUID flags from the host VM to the CPU, to allow enabling/disabling 
>>> branch prediction features in the Intel CPU. (bsc#1068032) 
>>>
>>> Can anybody point me to the relevant qemu patches? 
>>>
>>> Thanks! 
>>>
>>> Greets, 
>>> Stefan 
>>>
>>
>>
> 

[-- Attachment #2: 0065-i386-kvm-MSR_IA32_SPEC_CTRL-and-MSR.patch --]
[-- Type: text/x-patch, Size: 5703 bytes --]

>From b4fdfeb4545c09a0fdf01edc938f9cce8fcaa5c6 Mon Sep 17 00:00:00 2001
From: Wei Wang <wei.w.wang@intel.com>
Date: Tue, 7 Nov 2017 16:39:49 +0800
Subject: [PATCH] i386/kvm: MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD

CPUID(EAX=0X7,ECX=0).EDX[26]/[27] indicates the support of
MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD. Expose the CPUID
to the guest. Also add the support of transferring the MSRs during live
migration.

Signed-off-by: Wei Wang <wei.w.wang@intel.com>
[BR: BSC#1068032 CVE-2017-5715]
Signed-off-by: Bruce Rogers <brogers@suse.com>
---
 target/i386/cpu.c     |  3 ++-
 target/i386/cpu.h     |  4 ++++
 target/i386/kvm.c     | 15 ++++++++++++++-
 target/i386/machine.c | 20 ++++++++++++++++++++
 4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 55f72b679f..01761db3fc 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2823,13 +2823,14 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
     case 7:
         /* Structured Extended Feature Flags Enumeration Leaf */
         if (count == 0) {
+            host_cpuid(index, 0, eax, ebx, ecx, edx);
             *eax = 0; /* Maximum ECX value for sub-leaves */
             *ebx = env->features[FEAT_7_0_EBX]; /* Feature flags */
             *ecx = env->features[FEAT_7_0_ECX]; /* Feature flags */
             if ((*ecx & CPUID_7_0_ECX_PKU) && env->cr[4] & CR4_PKE_MASK) {
                 *ecx |= CPUID_7_0_ECX_OSPKE;
             }
-            *edx = env->features[FEAT_7_0_EDX]; /* Feature flags */
+            *edx = env->features[FEAT_7_0_EDX] | *edx;
         } else {
             *eax = 0;
             *ebx = 0;
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index a458c3af9b..9aa2480c63 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -333,6 +333,7 @@
 #define MSR_IA32_APICBASE_BASE          (0xfffffU<<12)
 #define MSR_IA32_FEATURE_CONTROL        0x0000003a
 #define MSR_TSC_ADJUST                  0x0000003b
+#define MSR_IA32_SPEC_CTRL              0x00000048
 #define MSR_IA32_TSCDEADLINE            0x6e0
 
 #define FEATURE_CONTROL_LOCKED                    (1<<0)
@@ -639,6 +640,8 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 
 #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network Instructions */
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation Single Precision */
+#define CPUID_7_0_EDX_SPEC_CTRL     (1U << 26)
+#define CPUID_7_0_EDX_PRED_CMD      (1U << 27)
 
 #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
 #define CPUID_XSAVE_XSAVEC     (1U << 1)
@@ -1181,6 +1184,7 @@ typedef struct CPUX86State {
 
     uint64_t xss;
 
+    uint64_t spec_ctrl;
     TPRAccess tpr_access_type;
 } CPUX86State;
 
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 55865dbee0..b35f02064b 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -75,6 +75,7 @@ static bool has_msr_star;
 static bool has_msr_hsave_pa;
 static bool has_msr_tsc_aux;
 static bool has_msr_tsc_adjust;
+static bool has_msr_spec_ctrl;
 static bool has_msr_tsc_deadline;
 static bool has_msr_feature_control;
 static bool has_msr_misc_enable;
@@ -1096,6 +1097,10 @@ static int kvm_get_supported_msrs(KVMState *s)
                     has_msr_tsc_adjust = true;
                     continue;
                 }
+                if (kvm_msr_list->indices[i] == MSR_IA32_SPEC_CTRL) {
+                    has_msr_spec_ctrl = true;
+                    continue;
+                }
                 if (kvm_msr_list->indices[i] == MSR_IA32_TSCDEADLINE) {
                     has_msr_tsc_deadline = true;
                     continue;
@@ -1667,6 +1672,9 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
     if (has_msr_xss) {
         kvm_msr_entry_add(cpu, MSR_IA32_XSS, env->xss);
     }
+    if (has_msr_spec_ctrl) {
+        kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, env->spec_ctrl);
+    }
 #ifdef TARGET_X86_64
     if (lm_capable_kernel) {
         kvm_msr_entry_add(cpu, MSR_CSTAR, env->cstar);
@@ -2081,7 +2089,9 @@ static int kvm_get_msrs(X86CPU *cpu)
     if (has_msr_xss) {
         kvm_msr_entry_add(cpu, MSR_IA32_XSS, 0);
     }
-
+    if (has_msr_spec_ctrl) {
+        kvm_msr_entry_add(cpu, MSR_IA32_SPEC_CTRL, 0);
+    }
 
     if (!env->tsc_valid) {
         kvm_msr_entry_add(cpu, MSR_IA32_TSC, 0);
@@ -2303,6 +2313,9 @@ static int kvm_get_msrs(X86CPU *cpu)
         case MSR_IA32_XSS:
             env->xss = msrs[i].data;
             break;
+        case MSR_IA32_SPEC_CTRL:
+            env->spec_ctrl = msrs[i].data;
+            break;
         default:
             if (msrs[i].index >= MSR_MC0_CTL &&
                 msrs[i].index < MSR_MC0_CTL + (env->mcg_cap & 0xff) * 4) {
diff --git a/target/i386/machine.c b/target/i386/machine.c
index 78ae2f986b..a6d429ad1a 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -868,6 +868,25 @@ static const VMStateDescription vmstate_xss = {
     }
 };
 
+static bool spec_ctrl_needed(void *opaque)
+{
+    X86CPU *cpu = opaque;
+    CPUX86State *env = &cpu->env;
+
+    return env->spec_ctrl != 0;
+}
+
+static const VMStateDescription vmstate_spec_ctrl = {
+    .name = "cpu/spec_ctrl",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .needed = spec_ctrl_needed,
+    .fields = (VMStateField[]) {
+        VMSTATE_UINT64(env.spec_ctrl, X86CPU),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
 #ifdef TARGET_X86_64
 static bool pkru_needed(void *opaque)
 {
@@ -1049,6 +1068,7 @@ VMStateDescription vmstate_x86_cpu = {
         &vmstate_msr_hyperv_stimer,
         &vmstate_avx512,
         &vmstate_xss,
+        &vmstate_spec_ctrl,
         &vmstate_tsc_khz,
 #ifdef TARGET_X86_64
         &vmstate_pkru,

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Paolo Bonzini]

On 04/01/2018 21:15, Stefan Priebe - Profihost AG wrote:
> attached the relevant patch for everybody who needs it.

This is the original patch from Intel, which doesn't work unless you
have a patched kernel (which you almost certainly don't have) and
doesn't even warn you about that.

In other words, it's rubbish.  Please read
https://www.qemu.org/2018/01/04/spectre/ several times, until you
understand why there is no urgent need to update QEMU.

Days are 24 hours for QEMU developers just like for you (and believe me,
we wished several times that they weren't during the last two months).
We are prioritizing the fixes according to their effect in mitigating
the vulnerability, their applicability and the availability of patches
to the lower levels of the stack.  Right now, the most urgent part is
the simple mitigations that can go in Linux 4.15 and stable kernels.

Paolo

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Stefan Priebe - Profihost AG]

Thanks! But it‘s very difficult to get all opinions all together.

SuSE Enterprise told me to update:
- kernel
- qemu
- Intel microcode

And the released already updates for all of them.

Stefan

Excuse my typo sent from my mobile phone.

> Am 05.01.2018 um 09:33 schrieb Paolo Bonzini <pbonzini@redhat.com>:
> 
>> On 04/01/2018 21:15, Stefan Priebe - Profihost AG wrote:
>> attached the relevant patch for everybody who needs it.
> 
> This is the original patch from Intel, which doesn't work unless you
> have a patched kernel (which you almost certainly don't have) and
> doesn't even warn you about that.
> 
> In other words, it's rubbish.  Please read
> https://www.qemu.org/2018/01/04/spectre/ several times, until you
> understand why there is no urgent need to update QEMU.
> 
> Days are 24 hours for QEMU developers just like for you (and believe me,
> we wished several times that they weren't during the last two months).
> We are prioritizing the fixes according to their effect in mitigating
> the vulnerability, their applicability and the availability of patches
> to the lower levels of the stack.  Right now, the most urgent part is
> the simple mitigations that can go in Linux 4.15 and stable kernels.
> 
> Paolo

Re: [Qemu-devel] CVE-2017-5715: relevant qemu patches

[Paolo Bonzini]

On 05/01/2018 11:40, Stefan Priebe - Profihost AG wrote:
> Thanks! But it‘s very difficult to get all opinions all together.
> 
> SuSE Enterprise told me to update:
> - kernel
> - qemu
> - Intel microcode
> 
> And the released already updates for all of them.

Yes, but live migrate an updated guest from updated to non-updated host
and you'll have a bad surprise.

Paolo

> Stefan
> 
> Excuse my typo sent from my mobile phone.
> 
> Am 05.01.2018 um 09:33 schrieb Paolo Bonzini <pbonzini@redhat.com
> <mailto:pbonzini@redhat.com>>:
> 
>> On 04/01/2018 21:15, Stefan Priebe - Profihost AG wrote:
>>> attached the relevant patch for everybody who needs it.
>>
>> This is the original patch from Intel, which doesn't work unless you
>> have a patched kernel (which you almost certainly don't have) and
>> doesn't even warn you about that.
>>
>> In other words, it's rubbish.  Please read
>> https://www.qemu.org/2018/01/04/spectre/ several times, until you
>> understand why there is no urgent need to update QEMU.
>>
>> Days are 24 hours for QEMU developers just like for you (and believe me,
>> we wished several times that they weren't during the last two months).
>> We are prioritizing the fixes according to their effect in mitigating
>> the vulnerability, their applicability and the availability of patches
>> to the lower levels of the stack.  Right now, the most urgent part is
>> the simple mitigations that can go in Linux 4.15 and stable kernels.
>>
>> Paolo