[pve-devel] Updated qemu pkg needed for Meltdown and Spectre?

Alexandre DERUMIER aderumier at odiso.com
Thu Jan 4 19:09:43 CET 2018


>From Paolo bonzini on qemu-devel

-- 
_posts/ 2018-01-04 -spectre.md | 60 ++++++++++++++++++++++++++++++++++++++++++++ 
1 file changed, 60 insertions(+) 
create mode 100644 _posts/ 2018-01-04 -spectre.md 

diff --git a/_posts/ 2018-01-04 -spectre.md b/_posts/ 2018-01-04 -spectre.md 
new file mode 100644 
index 0000000..1be86d0 
--- /dev/null 
+++ b/_posts/ 2018-01-04 -spectre.md 
@@ -0,0 +1,60 @@ 
+--- 
+layout: post 
+title: "QEMU and the Spectre and Meltdown attacks" 
+date: 2018-01-04 18:00:00 +0000 
+author: Paolo Bonzini and Eduardo Habkost 
+categories: [meltdown, spectre, security, x86] 
+--- 
+As you probably know by now, three critical architectural flaws in CPUs have 
+been recently disclosed that allow user processes to read kernel or hypervisor 
+memory through cache side-channel attacks. These flaws, collectively 
+named _Meltdown_ and _Spectre_, affect in one way or another almost 
+all processors that perform out-of-order execution, including x86 (from 
+Intel and AMD), POWER, s390 and ARM processors. 
+ 
+No microcode updates are required to block the _Meltdown_ attack; it is 
+enough to update the guest operating system to a version that separates 
+the user and kernel address spaces (known as _page table isolation_ for 
+the Linux kernel). Therefore, this post will focus on _Spectre_, and 
+especially on [CVE-2017-5715]( [ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715 | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715 ] ). 
+ 
+Fixing or mitigating _Spectre_ in general, and CVE-2017-5715 in particular, 
+requires cooperation between the processor and the operating system kernel or 
+hypervisor; the processor can be updated through microcode or millicode 
+patches to provide the required functionality. CVE-2017-5715 allows guests 
+to read potentially sensitive data from hypervisor memory; however, __patching 
+the host kernel is sufficient to block this attack__. 
+ 
+On the other hand, in order to protect the guest kernel from a malicious 
+userspace, updates are also needed to the guest kernel and, depending on 
+the processor architecture, to QEMU. Just like on bare-metal, the guest 
+kernel will use the new functionality provided by the microcode or millicode 
+updates. When running under a hypervisor, processor emulation is mostly out of 
+QEMU's scope, so QEMU's role in the fix is small, but nevertheless important. 
+In the case of KVM: 
+ 
+* QEMU configures the hypervisor to emulate a specific processor model. 
+For x86, QEMU has to be aware of new CPUID bits introduced by the microcode 
+update, and it must provide them to guests depending on how the guest is 
+configured. 
+ 
+* upon virtual machine migration, QEMU reads the CPU state on the source 
+and transmits it to the destination. For x86, QEMU has to be aware of new 
+model specific registers (MSRs). 
+ 
+Right now, there are no public patches to KVM that expose the new CPUID bits 
+and MSRs to the virtual machines, therefore there is no urgent need to update 
+QEMU; remember that __updating the host kernel is enough to protect the 
+host from malicious guests__. Nevertheless, updates will be posted to the 
+qemu-devel mailing list in the next few days, and a 2.11.1 patch release 
+will be released with the fix. 
+ 
+As of today, the QEMU project is not aware of whether similar changes will 
+be required for non-x86 processors. If so, they will also posted to the 
+mailing list and backported to recent stable releases. 
+ 
+For more information on the vulnerabilities, please refer to the [Google Security 
+Blog]( [ https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html | https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html ] ) 
+and [Google Project 
+Zero]( [ https://googleprojectzero.blogspot.it/2018/01/reading-privileged-memory-with-side.html | https://googleprojectzero.blogspot.it/2018/01/reading-privileged-memory-with-side.html ] ) 
+posts on the topic, as well as the [Spectre and Meltdown FAQ]( [ https://meltdownattack.com/#faq | https://meltdownattack.com/#faq ] ). 
-- 
2.14.3

Alexandre Derumier 
Ingénieur système et stockage 

Manager Infrastructure 


Fixe : +33 3 59 82 20 10 



125 Avenue de la république 
59110 La Madeleine 
[ https://twitter.com/OdisoHosting ] [ https://twitter.com/mindbaz ] [ https://www.linkedin.com/company/odiso ] [ https://www.viadeo.com/fr/company/odiso ] [ https://www.facebook.com/monsiteestlent ] 

[ https://www.monsiteestlent.com/ | MonSiteEstLent.com ] - Blog dédié à la webperformance et la gestion de pics de trafic

----- Mail original -----
De: "Fabian Grünbichler" <f.gruenbichler at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Jeudi 4 Janvier 2018 09:50:04
Objet: Re: [pve-devel] Updated qemu pkg needed for Meltdown and Spectre?

On Thu, Jan 04, 2018 at 07:17:54AM +0100, Stefan Priebe - Profihost AG wrote: 
> Hello, 
> 
> as far as i can see at least SuSE updated qemu for Meltdown and Spectre 
> to provide CPUID information to the guest. 
> 
> I think we need to patch qemu as well asap? Has anybody found the 
> relevant patches? 
> 
> https://www.pro-linux.de/sicherheit/2/41859/preisgabe-von-informationen-in-qemu.html 
> 
> Greets, 
> Stefan 

there seem to be no public (qemu) patches yet, once there are, we will 
review and include them. 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 




More information about the pve-devel mailing list