-
@stormi Updated on several Intel Xeon servers. Updated on new Intel and AMD (zen3) systems with IGC and r8125 chips. One issue... the base install does not include the standard firmware for the 8125.
-
@stormi My two host cluster (HP ProDesk 600 G6) updated without an issue. Let's see how the cluster is performing during the coming days.
-
@Andrew I just pushed an updated
linux-firmwareto testing, with firmware for rtl8125. Should be available within 10 minutes. -
@stormi r8125 firmware loads.
-
So, we found out the AMD vulnerability actually doesn't affect XCP-ng directly, because Xen doesn't use AMD's SEV features currently.
The other two vulnerabilities still need fixing, but they both can only be exploited if XCP-ng is used in an either unlikely or unsupported way. We'll fix them in due course, but won't push the update to everyone today as initially planned. We will delay them slightly to give them a chance to be grouped with future updates and thus cause less maintenance for users.
Thanks for the tests anyway: we will be able to publish these packages whenever we need now.
-
New security update candidates (kernel)
A new XSA was published on the 23rd of January, so we have a new security update to include it.
Security updates
kernel:
* Fix XSA-448 - Linux: netback processing of zero-length transmit fragment. An unprivileged guest can cause Denial of Service (DoS) of the host bysending network packets to the backend, causing the backend to crash. This was discovered through issues when using pfSense with wireguard causing random crashes of the host.
Test on XCP-ng 8.2
yum clean metadata --enablerepo=xcp-ng-testing yum update kernel --enablerepo=xcp-ng-testing rebootThe usual update rules apply: pool coordinator first, etc.
Versions:
kernel: 4.19.19-7.0.23.1.xcpng8.2
What to test
Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better.
Test window before official release of the updates
~2 days due to security updates. -
Did anyone install it? The 2 days delay is over and we'll publish today.
-
@stormi Yes, I installed it on a few running hosts. I did not have any kernel crashes before, and none after...
-
Installed here, works
-
@NielsH Kind of off topic but figured I'd mention it as I only recently discovered this.
Not sure what VMs you're running, but if they can survive being off for a short time (redundancy of services or planned outage) you can reboot the host using Smart Reboot under the Advanced tab. While it incurs some downtime, it allows for a much faster reboot time than migrating the VMs to another server and back.
I use local storage as well and it's been a game changer for dealing with pool patches.
-
The update has been published, thanks for the feedback and tests.
https://xcp-ng.org/blog/2024/01/26/january-2024-security-update/
-
@CJ said in Updates announcements and testing:
@NielsH Kind of off topic but figured I'd mention it as I only recently discovered this.
Not sure what VMs you're running, but if they can survive being off for a short time (redundancy of services or planned outage) you can reboot the host using Smart Reboot under the Advanced tab. While it incurs some downtime, it allows for a much faster reboot time than migrating the VMs to another server and back.
I use local storage as well and it's been a game changer for dealing with pool patches.
Cheers, thanks for the suggestion. In our case we actually are phashing out xcp-ng and are in the process of migrating to Proxmox since we can migrate with 30-35Gbit/s there. The disk performance is so much faster there we can perform all the updates in a single day instead of 2 weeks
Another issue we had was that VM migrations of very large VMs (usually 8cores+) are quite impactful. Because we want to use VMs with 24-48 cores and 128GB RAM as well it simply was not usable enough for us. There's several seconds, or sometimes even minutes of downtime during the last phase of the migration with the large VMs.
With Proxmox we have seen very little downtime (<1s) which we are very happy about.
-
New security update candidates (xen)
Two new XSAs were published on 30th of January.
- XSA-449 impacts PCI passthrough users.
- XSA-450 is only impacting the case where Xen is compiled without HVM support, that is not the case in XCP-ng. We therefore chose not to include this fix yet (will likely be included in future versions, maybe not part of a critical security update).
SECURITY UPDATES
xen-*:
* Fix XSA-449 - pci: phantom functions assigned to incorrect contexts. A malicious VM assigned with a PCI device could in some cases access data of a guest previously using the same PCI device. This requires PCI passthrough on a device using phantom functions and reassigning the same device to a new VM to be exploitable.
Test on XCP-ng 8.2
yum clean metadata --enablerepo=xcp-ng-testing yum update "xen-*" --enablerepo=xcp-ng-testing rebootThe usual update rules apply: pool coordinator first, etc.
Versions:
xen: 4.13.5-9.38.2.xcpng8.2
What to test
Normal use and anything else you want to test, if you are using PCI passthrough devices that's even better, but we also would be glad to have confirmation from others that their normal use case still works as intended.
Test window before official release of the updates
2 day because of security updates. -
This seems to be working fine on my two test systems but I don't do PCI passthrough.
-
@bleader I installed it on a bunch of busy hosts. All are fine, but none used PCI passthrough. The Rolling Pool Reboot in XO was very helpful.
-
The update has been published, thanks for testing.
https://xcp-ng.org/blog/2024/02/02/february-2024-security-update/
-
D Danp forked this topic on
-
New security update candidate (xen, microcode_ctl)
Two new XSAs were published on 12th of March, in cunjunction with microcode updates from Intel.
- XSA-452 The mitigation is currently off by default as it impacts only Atom CPUs, but can be enabled on Xen command line.
- XSA-453 This is a variation of Spectre-v1, which impacts a large panel of recent CPUs and architectures. This seems to not really be exploitable on Xen without specific changes and is not considered an emergency.
SECURITY UPDATES
xen-*:
* Fix XSA-452 - x86: Register File Data Sampling. Data from floating point, vector and integer register could be infered by an attacker on Atom processors, including data from a privileged context.
* Fix XSA-453 - GhostRace: Speculative Race Conditions. As mentioned, this is a Spectre-v1 variation that can allow an attacker to infer memory accross host and guests through a Use-After-Free flaw.microcode_ctl: Security updates from intel:- INTEL-SA-INTEL-SA-00972
- INTEL-SA-INTEL-SA-00982
- INTEL-SA-INTEL-SA-00898
- INTEL-SA-INTEL-SA-00960
- INTEL-SA-INTEL-SA-01045
Test on XCP-ng 8.2
yum clean metadata --enablerepo=xcp-ng-testing yum update "xen-*" microcode_ctl --enablerepo=xcp-ng-testing rebootThe usual update rules apply: pool coordinator first, etc.
Versions:
xen: 4.13.5-9.39.1.xcpng8.2microcode_ctl: 2.1-26.xs28.1.xcpng8.2
What to test
Normal use and anything else you want to test.
Test window before official release of the update
2 days because of security updates.
-
This is installed and working on my two test systems but they're both AMD so I'm not able to test the updated microcode.
-
@bleader Updates running on several old and new intel machines (including microcode update). Working fine so far. Rolling Pool Reboot is a helpful feature.
-
The update has been published, thank you for testing it out.
https://xcp-ng.org/blog/2024/03/15/march-2024-security-update/
