- Jan 31, 2010
HP and Dell have removed their BIOS updates.
I cannot say for sure, they should be up to date since they have windows updates set to automatic. By all means, even if one VM was outdated, there is nothing you can do to fix it, I have tried everything. Only full reinstall of the OS can fix it.Are your windows machines up-to-date? Maybe you are missing a patch?
some Intel microcode updates for some platforms/cpu models have been retracted.The Intel microcode update has been withdrawn because of bugs, so basically nobody can be reliably protected against Spectre today.
In the meanwhile, Linus explained how its use was crappy, and Google is developing retpoline to mitigate Spectre instead of relying to new x86 instructions.
So about Spectre, the situation is very confuse for now...
I suggest you get in touch with your hardware vendor and ask for a bios update. So far a lot of hardware vendors are quite busy to get this fixed.Can we actually deploy the intel-microcode package on Proxmox 5 without any issue ?
For the moment I don't have install this one, but we need it for spectre...
Dear Proxmox Staff Members,Second... Well, my understanding is, that for LXC containers it is even more problematic to not fix the problem as they share the hosts kernel afaik. So if the host is vulnerable to Meltdown and Spectre attacks, so will be your LXC containers. Due to the nature of sharing the same kernel with the host, LXC containers are all but isolated.
if a system is vulnerable to Meltdown, any user space process can dump the whole memory unless the kernel the process is running under has mitigations in place. this includes processes running in containers/namespaces, as they share a kernel with the host. KVM accelerated VMs are not vulnerable to Meltdown across the VM-hypervisor barrier, so you cannot dump the whole host memory from a process in a VM - Meltdown still affects the guest kernel though, so you can dump the whole guest memory from an unprivileged guest process in a VM.Dear Proxmox Staff Members,
Do you verify speedbird's reply?
Does privileged LXC containers can dump whole proxmox server memory?
We just published new kernels for Proxmox VE 4.x and 5.x, addressing Meltdown and Spectre in the kernel.
Please upgrade your Proxmox VE hosts via "apt update && apt dist-upgrade".
Proxmox VE 5.x: pve-kernel (4.13.13-34)
-- Proxmox Support Team <firstname.lastname@example.org> Sun, 7 Jan 2018 13:19:58 +0100
- cherry-pick / backport of KPTI / Meltdown fixes (from Ubuntu-4.13.0-23.25)
- add Google Spectre PoC fix for KVM
- fix objtool build regression
Proxmox VE 4.x: pve-kernel (4.4.98-102)
-- Proxmox Support Team <email@example.com> Sun, 7 Jan 2018 13:15:19 +0100
- cherry-pick / backport of KPTI / Meltdown fix (based on Ubuntu-4.4.0-107.130)
- add Google Spectre PoC fix for KVM
Proxmox VE project leader
Looks like you do not run latest kernel, the script shows here:...
Can someone suggest when patches for CVE-2017-5753 will be in proxmox kernel
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (117 opcodes found, which is >= 70, heuristic to be improved when official patches become available)
the current spectre_v2 mitigation in PVE kernel requires matching microcode updates (many of which have subsequently been retracted by Intel).
Hi fabian, with spectre v2, a guest vm can read host memory.if a system is vulnerable to Meltdown, any user space process can dump the whole memory unless the kernel the process is running under has mitigations in place. this includes processes running in containers/namespaces, as they share a kernel with the host. KVM accelerated VMs are not vulnerable to Meltdown across the VM-hypervisor barrier, so you cannot dump the whole host memory from a process in a VM - Meltdown still affects the guest kernel though, so you can dump the whole guest memory from an unprivileged guest process in a VM.
I have installed the latest OpenVZ kernel on several of our remaining Proxmox 3.x hosts using the .deb packages they provide. If you're using ZFS, you'll also need to add those modules to the new kernel. I have made .debs for ZFS 0.7.5 under Proxmox 3.x that you're welcome to (PM me), if you're willing to trust a complete stranger. If you're not using ZFS, the kernel alone is probably all you need.Hello Martin
I am wondering if there is any possibility of a fix for the kernel on version 3.4 ?
I have around 20 odd 3.4 machines which are rather difficult to move across due to the number of openvz containers!