XCP-ng 8.2 updates announcements and testing

gskger

@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.

stormi

@Andrew I just pushed an updated linux-firmware to testing, with firmware for rtl8125. Should be available within 10 minutes.

Andrew

@stormi r8125 firmware loads.

stormi

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.

bleader

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
reboot

The 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.

stormi

Did anyone install it? The 2 days delay is over and we'll publish today.

Andrew

@stormi Yes, I installed it on a few running hosts. I did not have any kernel crashes before, and none after...

olivierlambert

Installed here, works

CJ

@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.

bleader

The update has been published, thanks for the feedback and tests.

https://xcp-ng.org/blog/2024/01/26/january-2024-security-update/

NielsH

@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.

bleader

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
reboot

The 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.

JeffBerntsen

This seems to be working fine on my two test systems but I don't do PCI passthrough.

Andrew

@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.

bleader

The update has been published, thanks for testing.

https://xcp-ng.org/blog/2024/02/02/february-2024-security-update/

bleader

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
reboot

The usual update rules apply: pool coordinator first, etc.

Versions:

xen: 4.13.5-9.39.1.xcpng8.2
microcode_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.

JeffBerntsen

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.

Andrew

@bleader Updates running on several old and new intel machines (including microcode update). Working fine so far. Rolling Pool Reboot is a helpful feature.

bleader

The update has been published, thank you for testing it out.

https://xcp-ng.org/blog/2024/03/15/march-2024-security-update/

gduperrey

New update candidates for you to test!

As you may know, we group non-urgent updates together for a collective release, in order not to cause unnecessary maintenance for our users.

The moment to release such a batch has come, so here they are, ready for user tests before the final release.

openvswitch:
- CVE-2023-1668: Correct a flaw when processing an IP packet with protocol 0.
- CVE-2023-5366: Apply the patch for OpenFlow and neightbor discovery target with IPv6
- CVE-2023-3966: Correct a vulnerabity with "crafted Geneve packets causing invalid memory accesses and potential denial of service".
blktap:
- Synced with XS82ECU1056:
  - Bugfix for time out on NFS tasks which can sometimes exceed the configured value.
  - Improve the error handling for some lost iSCSI connection.
sm:
- Support NFS servers which only offer NFSv4. The discovery process for such servers differs from that of servers which offer also NFSv3, so the SR driver had to be improved.
- Synced with XS82ECU1056: bugfix on the path checker for DELL EqualLogic with iSCSI protocol
- Synced with XS82ECU1060: bugfix for when a host is unable to log into all iSCSI portals because there are separate independent Target Portal Groups inside the IQN.
util-linux: preparatory steps to support 4k-only disks.
xapi: Bugfix in a testing framework.
xcp-ng-pv-tools: Small fixes regarding VM stats reporting.
xcp-ng-xapi-plugins: Add check_installed function in updater plugin to test installed packages. This is a prerequisite for the upcoming XOSTOR release.

Test on XCP-ng 8.2

From an up to date host:

yum clean metadata --enablerepo=xcp-ng-testing
yum update --enablerepo=xcp-ng-testing blktap openvswitch sm-* util-linux xapi-* xcp-ng-pv-tools xcp-ng-xapi-plugins
reboot

The usual update rules apply: pool coordinator first, etc.

Versions

blktap: 3.37.4-3.1.xcpng8.2
openvswitch: 2.5.3-2.3.12.2.xcpng8.2
sm: 2.30.8-10.1.xcpng8.2
util-linux: 2.23.2-52.1.xcpng8.2
xapi: 1.249.32-2.2.xcpng8.2
xcp-ng-pv-tools: 8.2.0-12.xcpng8.2
xcp-ng-xapi-plugins: 1.10.0-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

~1 week.