fuckwit/kaiser/kpti

I

Idar Lund

Member
Jan 26, 2016
25
11
23
41
With the surfacing of the Intel CPU security vulnerability, and recent patches done to the linux kernel.
Sources;
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table/amp
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
According to these, the fix for linux is implemented in 4.15 (rc6) and 14.14.11+. Proxmox is running on 14.13. Will you backport this patch to 14.13 or will you upgrade the kernel to 14.14.11+? And when will you do so?
According to these sorces;
https://twitter.com/never_released/status/947935213010718720
https://twitter.com/jschauma/status/941447173245370368
..both Microsoft and Amazon is urging reboots of virtual hosts in the near future.
I don't want to stress you guys.. but we really need this patch upstream as fast as possible!
 
Last edited:
we are aware of the issue and tracking developments. we will follow Ubuntu's 4.13 backports and release updated kernel packages once those are available.
 
Sakis said:
Is this bug exploitable through a KVM guest using CPU host option?

Will it be a patch for PVE 3.X versions?
Click to expand...

not many details are known yet. we will provide patched kernels for 4.4 and 5.1 as soon as final patches are available. 3.4 is EOL, there haven't been any updates for quite a while, and there won't be any updates now either.
 
  • Like
Reactions: chrone
Hi all,

The application of this kernel security patch could result on noticeable performance impact, notably on servers. See for example this first bechmark from Phoronix :

https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

So I wonder if this patch should be applied mandatory. For exemple, on private virtualization cluster, like mines, it it perhaps not required to apply the patch (perhaps with the linux option nokpti), as security issues would not be very serious in this case, but I would see performance degradation of my cluster ?

Notice that a security patch on Xen, presently under embargo, should be published tomorrow, and it could be related to this flaw (in Intel architecture).
https://xenbits.xen.org/xsa/

But Xen applies patch to the kernel, not KVM.
 
alain said:
wonder if this patch should be applied mandatory. For exemple, on private virtualization cluster, like mines, it it perhaps not required to apply the patch (perhaps with the linux option nokpti), as security issues would not be very serious in this case, but I would see performance degradation of my cluster ?
Click to expand...

It's a kernel patch. It can be disabled with kernel parameter "pti=off" in grub config file.
 
alain said:
For exemple, on private virtualization cluster, like mines, it it perhaps not required to apply the patch (perhaps with the linux option nokpti), as security issues would not be very serious in this case
Click to expand...

I cannot imagine anything that runs without some kind of internet interaction nowadays. As long as simply browsing a webpage can exploit this bug, it should be fixed by not deliberately disabling a fix.

Maybe it's time to buy more AMD servers for data centers :-D
 
  • Like
Reactions: Idar Lund
Any news on when there's going to be an official update released? With all the info surfacing now, it seems to be a massive risk for all of us running VM environments.
 
there are no final public patches for Meltdown for either kernel 4.4 or 4.13 yet. once there are, we will review and include them ASAP.

Meltdown, which looks to be far more easily exploitable than Spectre, should not be usable from within KVM-enabled VMs to read host kernel memory, but containers are affected. compare the Xen advisory stating that only PV guests are affected by Meltdown (which they call "SP3").

concrete details regarding Spectre are still a bit rare, but AFAICT there are no public general PoCs yet allowing escaping from KVM, and Google Project Zero only talks about "When running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory". there will likely be a Qemu update that mitigates some of the Spectre attack vectors in combination with microcode updates, but again - there are no public details yet regarding this (yet).
 
  • Like
Reactions: rbodgers, gkovacs, taenzerme and 1 other person
fabian said:
there are no final public patches for Meltdown for either kernel 4.4 or 4.13 yet. once there are, we will review and include them ASAP.

Meltdown, which looks to be far more easily exploitable than Spectre, should not be usable from within KVM-enabled VMs to read host kernel memory, but containers are affected. compare the Xen advisory stating that only PV guests are affected by Meltdown (which they call "SP3").

concrete details regarding Spectre are still a bit rare, but AFAICT there are no public general PoCs yet allowing escaping from KVM, and Google Project Zero only talks about "When running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory". there will likely be a Qemu update that mitigates some of the Spectre attack vectors in combination with microcode updates, but again - there are no public details yet regarding this (yet).
Click to expand...

According to this, I assume we should make sure to have all VM CPUs set to kvm64 instead of host, isn't it?

Thank you
 
carles89 said:
According to this, I assume we should make sure to have all VM CPUs set to kvm64 instead of host, isn't it?
Click to expand...
I don't think so, as you probably want to have pcid CPU flag exposed to your guests in order to mitigate the performance loss coming from the Kernel/User page tables isolation feature once your guest kernels are updated.
 
Symbol said:
I don't think so, as you probably want to have pcid CPU flag exposed to your guests in order to mitigate the performance loss coming from the Kernel/User page tables isolation feature once your guest kernels are updated.
Click to expand...

But until the patch is released and hosts are upgraded, can anyone confirm if setting cpu to "kvm64" instead of "host" a temporary way to secure KVM VMs?

Thank you!
 
cpumodel=kvm64 protected you against spectre in your vm, but not meltdown. (you need to patch your guest kernel)

host kernel need to be updated to avoid that a vm access to memory of another vm.
 
  • Like
Reactions: carles89
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back