Many *.c files are symlinked while building, so along with generated *.h
files they ought to be removed. Conversely $(TARGET) doesn't need removing
twice.
Fixes: cb4fcf70b2 ("x86emul: parallelize SIMD test code building")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 774c382b28
master date: 2025-11-13 09:08:27 +0100
This is a partial backport of commit 63ebd0e964 ("releases: use newer
compression methods for tarballs"), but keeping gz as the only compression
method.
In addition to efficiency, this causes the tarball to use root/root ownership,
rather than leak whomever produced the tarball.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These files 'docs/misc/kconfig{,-language}.txt' were deleted, but
references are still present in Xen. Remove them to clean-up.
Fixes: 044503f61c ("docs: Delete kconfig docs to fix licensing violation")
Fixes: f80fe2b34f ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: c22b6dced0
master date: 2025-11-11 14:44:47 +0100
The stimer enlightment was removed from the defaults list in commit
e83077a3d1 ("libxl: don't enable synthetic timers by default") but the
corresponding docs change was not made. Removing from docs as enabling the
enlightenment will hang Windows 10 guests.
Fixes: e83077a3d1 ("libxl: don't enable synthetic timers by default")
Signed-off-by: James Dingwall <james@dingwall.me.uk>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: d510f9c143
master date: 2025-11-10 16:56:03 +0000
The default terminal settings in Linux will enable echo which interferes with
these tests. Set the value in the script to avoid failure caused by a settings
reset.
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 2f73ef4bd7)
Otherwise it's not possible for device models to map IRQs of devices on
segments different than 0. Keep the same function prototype and pass the
segment in the high 16bits of the bus parameter, like it's done for the
hypercall itself.
Amends: 7620c0cf9a ("PCI multi-seg: add new physdevop-s")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: b7838d12bd
master date: 2025-10-21 16:56:19 +0100
With large NR_CPUS on-stack cpumask_t variables are problematic. Now that
the IRQ handler can't be invoked in a nested manner anymore, we can
instead use a per-CPU variable. While we can't use scratch_cpumask in code
invoked from IRQ handlers, simply amend that one with a HPET-special form.
(Note that only one of the two IRQ handling functions can come into play
at any one time.)
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 80c7c67164
master date: 2025-10-29 09:02:53 +0100
If a SR-IOV card presents an I/O space inside a BAR the
code will continue to loop on the same card.
This is due to the missing increment of the cycle variable.
Fixes: a1a6d59862 ("pci: split code to size BARs from pci_add_device")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: f7091c0e1f
master date: 2025-10-27 15:52:20 +0100
Using dynamically allocated / maintained vectors has several downsides:
- possible nesting of IRQs due to the effects of IRQ migration,
- reduction of vectors available for devices,
- IRQs not moving as intended if there's shortage of vectors,
- higher runtime overhead.
As the vector also doesn't need to be of any priority (first and foremost
it really shouldn't be of higher or same priority as the timer IRQ, as
that raises TIMER_SOFTIRQ anyway), simply use the lowest one above the
legacy range. The vector needs reserving early, until it is known whether
it actually is used. If it isn't, it's made available for general use.
With a fixed vector, less updating is now necessary in
set_channel_irq_affinity(); in particular channels don't need transiently
masking anymore, as the necessary update is now atomic. To fully leverage
this, however, we want to stop using hpet_msi_set_affinity() there. With
the transient masking dropped, we're no longer at risk of missing events.
AMD interrupt remapping code so far didn't "return" a consistent MSI
address when translating an MSI message. Clear respective fields there, to
keep the related assertion in set_channel_irq_affinity() from triggering.
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 8ef32772b5
master date: 2025-10-27 15:51:42 +0100
Keeping channels enabled when they're unused is only causing problems:
Extra interrupts harm performance, and extra nested interrupts could even
have caused worse problems. However, on all Intel hardware I looked at
closely, a 0->1 transition of the enable bit causes an immediate IRQ.
Hence disabling channels isn't a good idea there. Set a "long" timeout
instead.
Along with that also "clear" the channel's "next event", for it to be
properly written by whatever the next user is going to want (possibly
avoiding too early an IRQ).
Further, along the same lines, don't enable channels early when starting
up an IRQ. This doesn't need to happen earlier than from
set_channel_irq_affinity() (once a channel goes into use the very first
time). This eliminates a single instance of
(XEN) [VT-D]INTR-REMAP: Request device [0000:00:1f.0] fault index 0
(XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt request
during boot. (Why exactly there's only one instance, when we use multiple
counters and hence multiple IRQs, I can't tell. My understanding would be
that this was due to __hpet_setup_msi_irq() being called only after
request_irq() [and hence the .startup handler], yet that should have
affected all channels.)
Fixes: 3ba523ff95 ("CPUIDLE: enable MSI capable HPET for timer broadcast")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 24f608dc90
master date: 2025-10-27 15:51:03 +0100
A .disable handler can't typically be re-used for .ack: The latter needs
to deal with IRQ migration, while the former shouldn't. Furthermore
invoking just irq_complete_move() isn't enough; one of
move_{native,masked}_irq() also needs invoking.
Fixes: 487a1cffd7 ("x86: Implement per-cpu vector for xen hypervisor")
Fixes: f821102450 ("x86: IRQ Migration logic enhancement")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: aed6278b2a
master date: 2025-10-21 14:11:45 +0200
By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
when linking xen.efi. Due to the nature of file symbols in COFF symbol
tables (see the code comment) the symbols_offsets[] entries for such
symbols would cause assembler warnings regarding value truncation. Of
course the resulting entries would also be both meaningless and useless.
Add a heuristic to get rid of them, really taking effect only when
--all-symbols is specified (otherwise these symbols are discarded
anyway).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 2f21ce1a6a
master date: 2025-10-21 14:10:46 +0200
The latest oxenstored from Xapi-project fails to start up:
launch-xenstore[1201]: Starting /usr/sbin/oxenstored...
launch-xenstore[1222]: Fatal error: exception
Dynlink.Error (Dynlink.Cannot_open_dll "Dynlink.Error (Dynlink.Cannot_open_dll
\"Failure(\\\"/usr/libexec/xen//ocaml/xsd_glue/xenctrl_plugin/domain_getinfo_v1.cmxs:
undefined symbol: xc_domain_getinfo_single\\\")\")")
This is because domain_getinfo_v1.cmxs isn't dynamically linked correctly.
Fill in the correct variable, and remove the xen prefix from xenctrl.
Reported-by: Edwin Török <edwin.torok@citrix.com>
Suggested-by: Edwin Török <edwin.torok@citrix.com>
Fixes: a6576011a4 ("ocaml/libs: Implement a dynamically-loaded plugin for Xenctrl.domain_getinfo")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit 343e01fd1d)
CONFIG_UCODE_SCAN_DEFAULT only exists in Xen 4.21. In older versions of xen,
use ucode=scan on the command line.
Fixes: 690655a511 ("CI: Include microcode for x86 hardware jobs")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
When Entrysign has been mitigated in firwmare, it is believed to be safe to
rely on the CPU patchloader again. This avoids us needing to maintain the
digest table for all new microcode indefinitely.
Relax the digest check when firmware looks to be up to date, and leave behind
a clear message when not.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
This is best-effort only. If a malicious microcode has been loaded prior to
Xen running, then all bets are off.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit ff8228ab46)
After initial publication, the SB-7033 / CVE-2024-36347 bulletin was updated
to list Zen5 CPUs as vulnerable. Use Fam1ah as an upper bound, and adjust the
command line documentation.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
Fixes: 630e8875ab ("x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit c2529496d0)
For Zen3-5 microcode blobs signed with the updated signature scheme, the
checksum field has been reused to be a min_revision field, referring to the
microcode revision which fixed Entrysign (SB-7033, CVE-2024-36347).
Cross-check this when trying to load microcode, but allow --force to override
it. If the signature scheme is genuinely different, a #GP will occur.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit b3f015b8ba)
EIO is not the only error that ucode_ops.apply_microcode() can produce.
EINVAL, EEXISTS and ENXIO can be generated too, each of which mean that Xen is
unhappy in some way with the proposed blob.
Some of these can be bypassed with --force, which will cause the parallel load
to be attempted.
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit e0bb712a28)
Currently, the URL where the ECLAIR MISRA C scan reports are saved
is hardcoded; making it configurable allows multiple runners and storage
servers to be used without resorting to publishing all artifacts
to the same report server.
Additionally, reports will be accessed publicly by using a proxy,
therefore the address that needs to be printed in GitLab analysis logs
is that of the public url, rather than the location where they are stored.
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove unneeded exports]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit bea38de1bd)
64-bit BAR memory address is truncated when removing a passthrough
pci device from guest since it uses "unsigned int".
So, change to use 64-bit type to fix this problem.
This is XSA-476 / CVE-2025-58149.
Fixes: b0a1af6167 ("libxenlight: implement pci passthrough")
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit 421432b822)
Commit 53859596c0 depends on the behavioral change introduced in
ee2eb6849d that inverted the initialization of the MSI-X and header vPCI
handlers. 53859596c0 requires the header to be initialized before MSI-X.
Change the order of initialization and adjust init_msix() to carve holes
for the MSI-X tables if necessary, since it will now run after the BARs
have been possibly mapped into the domain p2m.
Fixes: f9aea52a97 ("vpci/msix: improve handling of bogus MSI-X capabilities")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Callers can pass in a vpmask which exceeds d->max_vcpus. Prevent out-of-bound
reads of d->vcpu[].
This is XSA-475 / CVE-2025-58148.
Fixes: 728acba1ba ("viridian: use hypercall_vpmask in hvcall_ipi()")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: cc64c24502
master date: 2025-10-21 14:10:13 +0200
Callers can pass vp/mask values which exceed the size of vpmask->mask. Ensure
we only set bits which are within bounds.
This is XSA-475 / CVE-2025-58147.
Fixes: b4124682db ("viridian: add ExProcessorMasks variants of the flush hypercalls")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 36e90c4ef1
master date: 2025-10-21 14:09:37 +0200
When the fixes commit re-arranged the code, it made edd=off jump to the
mbr code instead of returning from the function. Previously edd_done
was immediately before ret and skipped the MBR check.
Replace edd_done with .Ledd_mbr_sig for the start of the MBR checking,
and replace .Ledd_mbr_sig_skip with .Ledd_done to exit from the function.
edd=off jumps to .Ledd_done to return from the function, and internal
jumps go to .Ledd_mbr_sig to check edd=skipmbr.
Fixes: 5ec164fd61 ("x86/boot: re-arrange how/when we do disk I/O")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 02e656f7c8
master date: 2025-10-16 10:25:27 +0200
The function returning zero is an error indication; we shouldn't try to
map MFN 0 and then treat that page as a context table.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: ef5b718cf8
master date: 2025-10-13 16:50:01 +0200
The variable can be cleared (set to false) by a non-init function's error
path (hwp_init_msrs()).
Fixes: 99c4570f82 ("cpufreq: Add Hardware P-State (HWP) driver")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
master commit: 4676e09b3c
master date: 2025-10-13 10:41:35 +0200
I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.
This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to carve a hole in
the p2m. This leads to errors like the one below being reported by Xen:
d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().
Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable. This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.
This fixes booting PVH dom0 on Supermicro AS -2126HS-TN servers with AMD
EPYC 9965 processors. The broken device is:
22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
There are multiple of those integrated controllers in the system, all
broken in the same way.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
master commit: 53859596c0
master date: 2025-10-10 11:02:39 +0200
Reading from the E9 port if the emergency console is active should return
0xe9 according to the documentation from Bochs:
https://bochs.sourceforge.io/doc/docbook/user/bochsrc.html
See `port_e9_hack` section description.
Fix Xen so it also returns the port address. OSes can use it to detect
whether the emergency console is available or not.
Fixes: d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: db5a3c31a6
master date: 2025-10-02 18:05:50 +0200
Otherwise the check for the SS feature in
check_memory_type_self_snoop_errata() fails unconditionally, which leads to
X86_FEATURE_XEN_SELFSNOOP never being set.
We could also avoid this by not doing the reset_cpuinfo() for the BSP in
identify_cpu(), because SS detection uses boot_cpu_data. However that
creates an imbalance on the state of the BSP versus the APs in the
identify_cpu() code.
I've opted for the less controversial solution of populating FEATURESET_1d
in generic_identify(), as the value is already there. The same is done for
the AMD faulting probe code. While there also populate the FEATURESET_1c
element, as the value is in context.
Fixes: f2663ca2e5 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 382dd0d166
master date: 2025-09-25 16:07:05 +0200
PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.
This shrinks PVH's DSDT substantially and prevents spuriously executing
a large amount of AML with no purpose at all.
Fixes: 062975dc9441("acpi: PVH guests need _E02 method")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: b59e564aa0
master date: 2025-09-25 09:18:55 +0200
In mca_cap_init function,the mcabanks_alloc allocates and
initializes an mca_banks structure for managing MCA banks,
setting up a bank map and storing the specified or default number
of banks.
After this we will call mcabanks_set(i, mca_allbanks);
The mcabanks_set function sets a specific bit in the bank_map of
an mca_banks structure, provided the structure, its bank_map, and
the bit index are valid.
At the end, we will call
mcabanks_free(xchg(&mca_allbanks, all));
This function is thread safe and does below:
1. Atomically exchanges the value of "mca_allbanks" with "all"
2. Returns the old value that was previously in "mca_allbanks"
So, when we will call mcabanks_free , that will free the memory.
The problem is that mcabanks_set(i, mca_allbanks) function is updating
mca_allbanks which will be freed via mcabanks_free later. This means
new mca_allbanks instance("all") will never get chance to update
it's bank_map.
Due to this when we will collect log from mcheck_mca_logout function ,
the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
and MCA logs will not be collected for any bank.
The fix is to solve this problem.
Fixes: 560cf418c8 ("x86/mcheck: allow varying bank counts per CPU")
Signed-off-by: Soham Dandapat <soham.dandapat@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 532988dccc
master date: 2025-09-09 08:18:11 +0200
When building Xen with GCC 12 with UBSAN and PVH_GUEST both enabled the
compiler emits the following errors:
arch/x86/setup.c: In function '__start_xen':
arch/x86/setup.c:1504:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
1504 | end = consider_modules(s, e, reloc_size + mask,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1505 | bi->mods, bi->nr_modules, -1);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/setup.c:1504:19: note: referencing argument 4 of type 'const struct boot_module[0]'
arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
686 | static uint64_t __init consider_modules(
| ^~~~~~~~~~~~~~~~
arch/x86/setup.c:1535:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
1535 | end = consider_modules(s, e, size, bi->mods,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1536 | bi->nr_modules + relocated, j);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/setup.c:1535:19: note: referencing argument 4 of type 'const struct boot_module[0]'
arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
686 | static uint64_t __init consider_modules(
| ^~~~~~~~~~~~~~~~
This seems to be the result of some function manipulation done by UBSAN
triggering GCC stringops related errors. Placate the errors by declaring
the function parameter as `const struct *boot_module` instead of `const
struct boot_module[]`.
Note that GCC 13 seems to be fixed, and doesn't trigger the error when
using `[]`.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 932898d449
master date: 2025-03-17 13:33:28 +0100
We have a mix of root and non-root containers, and are trying to become
rootless. This can cause the local CPIO fragements to end up being user:user
in the test environment.
Nothing seems to go wrong so far, but it's a trap waiting to happen.
Make everything consistently root for the initrds, irrespective of the
rootness of the container the test is running in.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit e3042c9fc2)
In order to safely acquire a reference for a foreign page mapping, the
P2M lock needs to be held until we have the reference in hand (or
getting one failed). Otherwise the page can change P2M type and
ownership in between.
This is CVE-2025-58145 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
master commit: 2275bf83a1
master date: 2025-09-09 14:12:57 +0200
I can't see what would make the 1st of the assertions safe: For example,
the P2M lock not being held, the foreign page may disappear before we
get to call page_get_owner_and_reference(), which hence may return NULL.
Even the 2nd, which appears to be safe safe, is lacking proper release
build fallbacks.
Drop the former in favor of an if(), and convert the latter to the
equivalent of what x86 uses: ASSERT_UNREACHABLE() plus putting of the
obtained page.
This is CVE-2025-58144 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
master commit: c5a6dd6850
master date: 2025-09-09 14:12:13 +0200
The reference TSC page is shared between all vCPUs, and the data stored in
the domain struct. However the handlers to set and clear it are not safe
against concurrent accesses. It's possible for two (or more) vCPUs to call
HV_X64_MSR_REFERENCE_TSC at the same time and cause the in-use reference
TSC page to be freed, while still being on the p2m. This creates a use-
after-free bug, where the page can end up mapped in another domain or used
by Xen while still being part of the original domain's p2m.
It's also possible to underflow the reference counter, as multiple
concurrent writes to HV_X64_MSR_REFERENCE_TSC can create an imbalance on
the number of put_page_and_type() calls.
Introduce a lock to protect the reference TSC domain field, thus
serializing concurrent vCPU accesses.
This is CVE-2025-58143 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 45729a510a
master date: 2025-09-09 14:12:00 +0200
The function is called unconditionally, regardless of whether the SIM page
is mapped. Avoid a NULL pointer dereference in
viridian_synic_deliver_timer_msg() by checking whether the SIM page is
mapped.
This is CVE-2025-58142 / part of XSA-472.
Fixes: 26fba3c855 ('viridian: add implementation of synthetic timers')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 3a7b4f2897
master date: 2025-09-09 14:11:34 +0200
The function is only called when the MSR has the enabled bit set, but even
then the page might not be mapped because the guest provided gfn is not
suitable.
Prevent a NULL pointer dereference in update_reference_tsc() by checking
whether the page is mapped.
This is CVE-2025-27466 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5776a2e9db
master date: 2025-09-09 14:11:09 +0200
Jan reports the following exception when using the cycle debugging:
Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL, RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD]
Traceback (most recent call last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 594, in <module>
sys.exit(main())
^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 588, in main
crunch_numbers(state)
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 366, in crunch_numbers
(state.names[feat], repl(seen), repl(to_process)))
^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in repl
return "[" + ", ".join((state.names[x] for x in l)) + "]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in <genexpr>
return "[" + ", ".join((state.names[x] for x in l)) + "]"
~~~~~~~~~~~^^^
KeyError: 534
make[2]: *** [/local/xen.git/xen/include/xen/lib/x86/Makefile:9: cpuid-autogen.h] Error 1
This is caused by commit ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature
names") being rather lazy and marking dependenices on unknown features.
Introduce a helper to pick the known features in a range, and use it for
ARCH_CAPS.
Additionally, remove trailing whitespace and an unnecessary line continuation
from the debug print.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature names")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 5edb4ccff6
master date: 2025-09-01 19:54:21 +0100
With the processing done linearly (rather than recursively), checking
whether any of the features was previously seen is wrong: That would
e.g. trigger for this simple set of dependencies
X: [A, B]
A: [C]
B: [C]
(observed in reality when making AMX-AVX512 dependent upon both
AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list
of dependents). But checking the whole accumulated set also isn't
necessary - just checking the feature we're processing dependents of is
sufficient. We may detect a cycle later that way, but we still will
detect it. What we need to avoid is adding a feature again when we've
already seen it.
As a result, seeding "seen[]" with "feat" isn't necessary anymore.
Fixes: fe4408d180 ("xen/x86: Generate deep dependencies of features")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 3999ff0d30
master date: 2025-09-01 13:07:53 +0200
EFI code path split options from EFI LoadOptions fields in 2
pieces, first EFI options, second Xen options.
"get_argv" function is called first to get the number of arguments
in the LoadOptions, second, after allocating enough space, to
fill some "argc"/"argv" variable. However the first parsing could
be different from second as second is able to detect "--" argument
separator. So it was possible that "argc" was bigger than the
initialized portion of "argv" array, leading to potential
uninitialized pointer dereference, in particular a string like
"-- a b c" would lead to crashes.
Using EFI shell is possible to pass any kind of string in
LoadOptions.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: 375f0dd538
master date: 2025-09-01 13:07:01 +0200
SMBIOS specification dictates that tables should have a minimal length.
This commit introduces further validation for user-input SMBIOS tables.
As per SMBIOS Reference Specification:
* Type 0: For version 2.3 and later implementations, the length is at least 14h
* Type 1: 1Bh for 2.4 and later
* Type 2: at least 08h
* Type 3: 0Dh for version 2.1 and later
* Type 11: 5h (+ strings)
* Type 22: 1Ah (+ strings)
* Type 39: a minimum of 10h
Notably, this also fixes previously incorrect check for chassis handle in
smbios_type_2_init. Chassis handle is a WORD, therefore, the condition now
correctly checks for >= 13 instead of > 13.
hvmloader currently implements version 2.4
Furthermore, this commit introduces smbios_pt_copy helper function to substitute
previously repeating pattern of locating the struct in physical memory (via
get_smbios_pt_struct), checking the length and copying it into SMBIOS region.
Fixes: 4d23036e70 ("HVM firmware passthrough SMBIOS processing")
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 2f7d52f016
master date: 2025-08-27 11:26:33 +0200
* `sizeof_field` returns the size of a specific struct member
* `endof_field` returns the offset to the end of the member within the struct
It will be useful in upcoming layout checks of SMBIOS structs.
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: 17e66ca918
master date: 2025-08-27 11:26:33 +0200
The current code to restore the timer state on resume is incomplete. While
the local APIC Initial Count Register is saved and restored across
suspension (even if possibly no longer accurate since it's not adjusted to
account for the time spent in suspension), the TSC deadline MSR is not
saved and restored, hence hosts using the TSC deadline timer will likely
get stuck when resuming from suspension.
The lack of restoring of the TSC deadline MSR was mitigated by the raising
of a timer softirq in mwait_idle_with_hints() if the timer had expired,
previous to commit 3faf0866a3, which removed
that logic.
This patch fixes the usage of the TSC deadline timer with suspension, by
unconditionally raising a timer softirq on resume, that will take care of
rearming the hardware timer. Given that a timer softirq will be
unconditionally risen, there's no need to save and restore the APIC Initial
Count Register anymore either.
Note that secondary processors don't need this special treatment when
resuming, since they are offlined before suspension and brought back up
during resume, the first timer that gets setup will trigger a timer softirq
unconditionally, for example from sched_migrate_timers() that gets called
for each secondary processor.
Link: https://github.com/QubesOS/qubes-issues/issues/10110
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Fixes: fd1291a826 ('X86: Prefer TSC-deadline timer in Xen')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: 757abedabb
master date: 2025-08-27 09:33:12 +0200
There's no family check gating intel_init_ppin(), making it incorrect to
use on non Fam6 CPUs.
Emerald Rapids is the final CPU to have PPIN but lack the architectural
enumeration, so include it too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 49e6eb744e
master date: 2025-08-25 14:04:41 +0100
Otherwise the PCI accesses to segments different than the first one done by
the IOMMU initialization code would silently fail by returning all ones.
Introduce a new helper, called pci_setup(), and move both the creation of
PCI segment 0 internal data structures, plus the parsing of ACPI MMCFG
table to it. This moves acpi_mmcfg_init() slightly earlier from
acpi_boot_init() into pci_setup().
Note that further work will be needed to support systems where access
methods to segments different than 0 is not discoverable by Xen.
Fixes: 3950f2485b ('x86/x2APIC: defer probe until after IOMMU ACPI table parsing')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: c292772b49
master date: 2025-08-21 11:57:25 +0200
Fix the incorrect condition that causes hvm_alloc_legacy_ioreq_gfn()
to return INVALID_GFN even if the HVM param was installed properly by
the toolstack.
Fixes: 3486f398a3 (' x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN')
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 282ed258a5
master date: 2025-08-18 10:43:52 +0200
Jan Beulich