My bad, we were a bit late and I tried to be quick and forgot to move it... Just did that, should be good soon, it needs some time to sync repos.
Posts made by bleader
-
RE: Updates announcements and testing
-
RE: Updates announcements and testing
New security update candidate (xen)
Three new XSAs were published on 9th of April.
Notes:
- XSA-456 was published on various public mailing list but its entry is not yet on the xenbits page, hence the different link for this one.
- XSAs description to be completed later, early posting to provide more chances to run tests before final release.
- XSA-454 impacts all host running HVM or PVH guests on x86_64, therefore all supported architectures on XCP-ng.
- XSA-455 relates to XSA-407 (Branch Type Confusion) having a logical error, check its
VULNERABLE SYSTEMS
section for impacted systems. - XSA-456 should only impact Intel CPU as it is understood at this time.
SECURITY UPDATES
xen-*
:- Fix XSA-454 - x86 HVM hypercalls may trigger Xen bug check. HVM and PVH guests can DoS a host in some cases calling 32-bit-mode hypercalls with parameters that will lead the hypercall sanity checks to trigger a crash.
- Fix XSA-455 - x86: Incorrect logic for BTC/SRSO mitigations. Fix for XSA-407 was not properly used, meaning an attacker could be able to infer memory from host or other guests. All versions since 4.13.4-9.24.1 are vulnerable.
- Fix XSA-456 - x86: Native Branch History Injection. An attacker could infer memory of host or other guests by using the Native Branch History Ijnection flaw. This is an evolution of Spectre-BHB which was previously considered not to be a risk for Xen.
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.40.1.xcpng8.2
What to test
Normal use and anything else you want to test.
Test window before official release of the updates
~1 days because of security updates.
-
RE: Epyc VM to VM networking slow
@olivierlambert vm to host is impacted too, althrough less, reaching over 10Gbps on a zen2 epyc.
-
RE: High Fan Speed Issue on Lenovo ThinkSystem Servers
Could one of you try the
kernel-alt
package? It is not meant for production as it is not fully tested and supported, but if a higher patch level of the 4.19 helps, it could give us more idea of what's happening.EDIT: it should be updated to a new patch level soon-ish, so if current one does not fix, we should soon have another shot with a more recent update.
-
RE: Epyc VM to VM networking slow
@gskger It does seem quite lower than the 5950x and the 7600 we tested, but:
- it is a zen1 if I'm not mistaken
- in the 4 threads case, with 8 threads on the physical CPU, the VMs and dom0 are actually sharing ressources
- for single thread I guess the generation and memory speed could explain the difference.
I would say that this confirms these ryzen cpus are not really impacted either.
Thanks for sharing, I'll update the table tomorrow.
-
RE: Epyc VM to VM networking slow
@olivierlambert We did talk in DM before, I told him any data is always welcome, especially as I didn't even know this range of CPUs
-
RE: XZ Backdoor for SSH
My bad, forgot this was a package we took from CentOS 7, but this package was made prior to JiaT75 starting this journey.
For reference:
-
RE: Epyc VM to VM networking slow
@manilx thanks for the additional results, and yes, it is a pretty big issue, but even with multiple people looking at it or trying to help out, we were not able to pinpoint the root cause yet
-
RE: Epyc VM to VM networking slow
@timewasted Thanks for sharing, as long as we haven't found a solution, it is always good to have more feedback, so thanks for that.
For FreeBSD it usus the same principle of network driver, but it seems to have lower performances, not only on EPYC system, this could be another investigation for later
I am indeed surprised by your vm/host results, I generally get a way greater performance there in my tests. I agree the management NIC speed should not impact it at all⦠You said no tuning so I guess no pinning or anything, therefore I don't really see why that is right now.
-
RE: XZ Backdoor for SSH
I'll investigate this further today to be a 100% sure, but the version of XZ we have is not impacted, plus we build from a copied tarball in our build system, so even if the tarball of this version was impacted later than the time we downloaded the tarball we would not be impacted.
We'll make a communication about it once I finished double checking it.
-
RE: Updates announcements and testing
The update has been published, thank you for testing it out.
https://xcp-ng.org/blog/2024/03/15/march-2024-security-update/
-
RE: Updates announcements and testing
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.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.
-
RE: High Fan Speed Issue on Lenovo ThinkSystem Servers
@rmaclachlan it could be the kernel, but there is Xen between the kernel and the hardware, which does for example handle the cpu frequency scaling. If you're on a test machine and can spare the time maybe you can give a shot to Xen 4.17 on XCP-ng 8.3. But to be honest I would not think this will change much, but who knows until it's tested
-
RE: High Fan Speed Issue on Lenovo ThinkSystem Servers
Given Rix_IT is on 8.2 that allows us to know both versions seems affected, thanks!
-
RE: Bad Performance CPU? get-cpufreq-para failed
@high-voltages you also can try
xenpm start 10
to gather info for 10s and it will print a sumarry at the end, in my case it had each core average frequency, not sure you'll get it too, but you can give it a shot. -
RE: High Fan Speed Issue on Lenovo ThinkSystem Servers
I may be wrong, but I don't think we have much in term of controlling/handling cpu fans and such in XCP-ng or in Xen itself for that matter.
@rmaclachlan were you testing on 8.2 too? I don't think there is much chance 8.3 beta 2 would change much in this regard, but it would be interesting to be sure this also happens on it.
-
RE: Bad Performance CPU? get-cpufreq-para failed
In guests (even privileded guest like dom0),
/proc/cpuinfo
reports only what xen exposes to it, it generally is shown as fixed value.You can only get some more insight using
xenpm
when it actually shows something. I found it commonly having parts working or not depending on the CPU. On a xeon here, I get the same as you withget-cpufreq-para
but you can have a look atget-cpufreq-average
which is generally working, here you can see the frequency moving, on an idle machine it should be lower, and get higher with load.Hope this helps.
-
RE: Please help me with the answer
Hello, not sure I can actually help, but I'll try to bring some info.
-
As far as I know, Xen handles the cpu scaling by default, as you checked with
xenpm
. Therefore I would guess it does not expose the p-states to the guest. When reading/proc/cpuinfo
the kernel will call show_cpuinfo() function will call arch_freq_get_on_cpu() which ends up checking support for p-states on fallback to a simpler version that will in our case probably always report the base clock. At least that's my understanding, I went through this quickly and may have missed bits, but sound "logical" to me. -
I think the guest tools won't help you there, they report information from host to guest only, and as mentionned in the first point the guest frequency reporting is not live frequency.
-
The only way I see how to confirm your VM is using turbo clocks would be to pin your VM vcpus to fixed pcpus, load the VM and check these pcpu with xenpm as you were doing.
-
It is interesting to me you're seeing turbo clocks there at all, from my tests for some other stuff, on epyc I actually never saw the clock go above the base clock, did you do anything specific to enable it? I guess BIOS setup to enable turbo, and maybe enable it with
xenpm
?
-
-
RE: Updates announcements and testing
The update has been published, thanks for testing.
https://xcp-ng.org/blog/2024/02/02/february-2024-security-update/
-
RE: Updates announcements and testing
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.