Meltdown and Spectre Linux Kernel fixes

Host:
4.13.13-3-pve #1 SMP PVE 4.13.13-34 (Sun, 7 Jan 2018 13:19:58 +0100) x86_64 GNU/Linux
1x Intel Xeon E3-1240v6
Supermicro X11SSL-F
16GB ECC DDR-4
Adaptec 8405 RAID Controller
2x Samsung SM863 SSD with Raid-1

only one VM:
3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
KVM, Debian 8

After that we install again tho old kernel...
3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux
Ufff, so finally better not parching proxmox kernel????
 
the Proxmox kernel is still patched. Only the VM has against the old kernel
 
I tried to upgrade with this

Code:
apt update && apt dist-upgrade

and end up with this result

Code:
Ign:1 http://ftp.us.debian.org/debian stretch InRelease

Hit:2 http://ftp.us.debian.org/debian stretch Release

Ign:4 https://enterprise.proxmox.com/debian/pve stretch InRelease                 

Err:5 https://enterprise.proxmox.com/debian/pve stretch Release

  401  Unauthorized

Hit:6 http://security.debian.org stretch/updates InRelease

Reading package lists... Done

E: The repository 'https://enterprise.proxmox.com/debian/pve stretch Release' does not have a Release file.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.

is there something that I am doing wrong with this?

my current version is
Code:
Linux prox01 4.10.15-1-pve #1 SMP PVE 4.10.15-15
 
I tried to upgrade with this

Code:
apt update && apt dist-upgrade

and end up with this result

Code:
Ign:1 http://ftp.us.debian.org/debian stretch InRelease

Hit:2 http://ftp.us.debian.org/debian stretch Release

Ign:4 https://enterprise.proxmox.com/debian/pve stretch InRelease                

Err:5 https://enterprise.proxmox.com/debian/pve stretch Release

  401  Unauthorized

Hit:6 http://security.debian.org stretch/updates InRelease

Reading package lists... Done

E: The repository 'https://enterprise.proxmox.com/debian/pve stretch Release' does not have a Release file.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.

is there something that I am doing wrong with this?

my current version is
Code:
Linux prox01 4.10.15-1-pve #1 SMP PVE 4.10.15-15

https://pve.proxmox.com/wiki/Package_Repositories#_proxmox_ve_no_subscription_repository
 
is it possible to do an upgrade from stretch to jessie or wheezy?

Code:
Err:3 http://download.proxmox.com/debian/pve jessie InRelease

  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C23AC7F49887F95A

Reading package lists... Done

W: GPG error: http://download.proxmox.com/debian/pve jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C23AC7F49887F95A

E: The repository 'http://download.proxmox.com/debian/pve jessie InRelease' is not signed.

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

N: See apt-secure(8) manpage for repository creation and user configuration details.
 
Just trying things on this, I am still new with proxmox and wanted to learn more about. thx for the input.
 
Just trying things on this, I am still new with proxmox and wanted to learn more about. thx for the input.

Please do not add unrelated questions, instead open a new thread for new questions.
 
Host:
4.13.13-3-pve #1 SMP PVE 4.13.13-34 (Sun, 7 Jan 2018 13:19:58 +0100) x86_64 GNU/Linux
1x Intel Xeon E3-1240v6
Supermicro X11SSL-F
16GB ECC DDR-4
Adaptec 8405 RAID Controller
2x Samsung SM863 SSD with Raid-1

only one VM:
3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
KVM, Debian 8

After that we install again tho old kernel...
3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux

did you pass the PCID flag to your VM? otherwise, a big performance loss / load increase is expected..
 
Fabian, PCID is not since 4.14 kernel?

I sure hope that most distros followed the upstream stable maintainers and backported PCID support along with KPTI.. Debian did for 3.16 in Jessie and 4.9 in Stretch..
 
We have some fairly old Dell PowerEdge servers (just about in warranty) that haven't had BIOS updates in over a year . so I suspect they won't get a BIOS update for Meltdown/Spectre. I was wondering if adding the intel-microcode package from the non-free Debian repo would help (assuming that's the one that will get Meltdown/Spectre fixes in the near future - Intel released new microcode on 8th Jan, but intel-microcode is dated 20170707 at the moment).
 
We have some fairly old Dell PowerEdge servers (just about in warranty) that haven't had BIOS updates in over a year . so I suspect they won't get a BIOS update for Meltdown/Spectre. I was wondering if adding the intel-microcode package from the non-free Debian repo would help (assuming that's the one that will get Meltdown/Spectre fixes in the near future - Intel released new microcode on 8th Jan, but intel-microcode is dated 20170707 at the moment).

You could manually install the latest package, according to https://forum.proxmox.com/threads/meltdown-and-spectre-for-newbie.39183/#post-194316

Depending on cpu, it could work or not. I have tried on both Jessie and Stretch, but not production servers and without performance benchmarks.

WORKING
Code:
# dpkg -l | grep intel-microcode
ii  intel-microcode                        3.20180108.1                       amd64        Processor microcode firmware for Intel CPUs
#dmesg | grep microcode
[    0.000000] microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.98-4-pve #1 SMP PVE 4.4.98-104 (Mon, 15 Jan 2018 09:34:49 +0100) x86_64
CPU is Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz

....
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  YES
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  NOT VULNERABLE  (IBRS mitigates the vulnerability)
....

NOT WORKING
Code:
# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64
CPU is Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz

VE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  NO
*     The SPEC_CTRL CPUID feature bit is set:  NO
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

NOT WORKING
Code:
# dpkg -l | grep microcode
ii  intel-microcode                    3.20180108.1                         amd64        Processor microcode firmware for Intel CPUs
# dmesg | grep microcode
[    0.000000] microcode: CPU0 microcode updated early to revision 0x19, date = 2013-06-21
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.98-4-pve #1 SMP PVE 4.4.98-104 (Mon, 15 Jan 2018 09:34:49 +0100) x86_64
CPU is Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
...
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

But, I repeat, those are not production servers, they have booted all right, I didn't notice obvious issues. But, everybody says they are unstable, and are waiting for retpoline mitigation.
 
You could manually install the latest package, according to https://forum.proxmox.com/threads/meltdown-and-spectre-for-newbie.39183/#post-194316

Depending on cpu, it could work or not. I have tried on both Jessie and Stretch, but not production servers and without performance benchmarks.

WORKING
Code:
# dpkg -l | grep intel-microcode
ii  intel-microcode                        3.20180108.1                       amd64        Processor microcode firmware for Intel CPUs
#dmesg | grep microcode
[    0.000000] microcode: CPU0 microcode updated early to revision 0xc2, date = 2017-11-16
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.98-4-pve #1 SMP PVE 4.4.98-104 (Mon, 15 Jan 2018 09:34:49 +0100) x86_64
CPU is Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz

....
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  YES
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  NOT VULNERABLE  (IBRS mitigates the vulnerability)
....

NOT WORKING
Code:
# dmesg | grep microcode
[    0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.13.13-5-pve #1 SMP PVE 4.13.13-36 (Mon, 15 Jan 2018 12:36:49 +0100) x86_64
CPU is Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz

VE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  NO
*     The SPEC_CTRL CPUID feature bit is set:  NO
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

NOT WORKING
Code:
# dpkg -l | grep microcode
ii  intel-microcode                    3.20180108.1                         amd64        Processor microcode firmware for Intel CPUs
# dmesg | grep microcode
[    0.000000] microcode: CPU0 microcode updated early to revision 0x19, date = 2013-06-21
# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.98-4-pve #1 SMP PVE 4.4.98-104 (Mon, 15 Jan 2018 09:34:49 +0100) x86_64
CPU is Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
...
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

But, I repeat, those are not production servers, they have booted all right, I didn't notice obvious issues. But, everybody says they are unstable, and are waiting for retpoline mitigation.

Actually, I think that I will parshes my proxmox HOST with last proxmox kernel and the same with each VM en centos7, but I will no install dell bios or microcode for variant2... I know that the still an risk of security, but can't give an bad performance service to our client solving the variant2... it's not an solution in our case. The 2 solution are bad (or performance or security risk), but bad performance means that all client go to other proveedor...
 
Actually, I think that I will parshes my proxmox HOST with last proxmox kernel and the same with each VM en centos7, but I will no install dell bios or microcode for variant2... I know that the still an risk of security, but can't give an bad performance service to our client solving the variant2... it's not an solution in our case. The 2 solution are bad (or performance or security risk), but bad performance means that all client go to other proveedor...

I'm waiting for retpoline integration in ubuntu kernel, seem to be faster to fix variant2.
 
Hi all,
I understood that there is still a long way to go until we overcome this mess with Meltdown and Spectra which obviously is not the fault of Proxmox developer. My regards to all Proxmox stuff member I am sure you are doing the best to keep us safe as possible. Keep up the great work !

Well I updated my Proxmox 4.x Host to the newest Kenrnel and updates available and actually was lucky to have no problem with that. Mashine is fine und nothing negative to report. The Server has a Intel Xeon E3-1245 so I also got the Option to turn PCID on after Update was done but which is still off right now.

My Question is : Do I have to turn it on to be protected against Meltdown ? I have no loss of CPU Load after Update so I did not turn it on.
Did I correctly understand that this would only (if) protect the VM running on the Host but not actually protect the Proxmox Host (Node) itself ?
 
Hi all,
I understood that there is still a long way to go until we overcome this mess with Meltdown and Spectra which obviously is not the fault of Proxmox developer. My regards to all Proxmox stuff member I am sure you are doing the best to keep us safe as possible. Keep up the great work !

Well I updated my Proxmox 4.x Host to the newest Kenrnel and updates available and actually was lucky to have no problem with that. Mashine is fine und nothing negative to report. The Server has a Intel Xeon E3-1245 so I also got the Option to turn PCID on after Update was done but which is still off right now.

My Question is : Do I have to turn it on to be protected against Meltdown ? I have no loss of CPU Load after Update so I did not turn it on.
Did I correctly understand that this would only (if) protect the VM running on the Host but not actually protect the Proxmox Host (Node) itself ?
Do you have also updated your VM kernels? or only your HOST kernel? If your VM have "host" cpu configuration, no need to pass this option, it only needed if you have other cpu type configurated.
 

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!

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!