For XPTI enabled VMs, restore_all_guest() copies most of the active L4
pagetable into the per-CPU root_pgt. The L4 is read via the
directmap.
Unfortunately, there was no accounting for the fact that PV guests
have short directmaps. For an L4 living beyond the 5T boundary (3.5T
for CONFIG_BIGMEM), Xen will copy arbitrary data from guest-controlled
virtual address space into the per-CPU root_pgt, instead of the
intended L4.
Xen has per-domain mappings for the LDT and GDT, with two pages
reserved for Xen's use in the GDT but only one in use. Reuse GDT page
15 to map the effective L4. The GDT limit keeps implicit accesses out
of this page.
We update this mapping in make_cr3(), the only place a non-empty value
of v->arch.cr3 is written into a guest's vcpu struct, for two reasons.
First is reference counting: this makes it easier to argue that the
reference for v->arch.cr3 itself covers the reference for the mapping.
Secondly, this guarantees that all updates, even updates made in
shadow mode, result in an update to the mapping. During live
migration, it's possible for guest_get_eff_kern_l1e() to result in a
modified value of v->arch.cr3 (sketch below); placing the mapping
update at make_cr3() catches this, while other candidate locations
like write_ptbase() and toggle_guest_mode() don't.
Note that we introduce the idea of an "effective L4" here, to mean
"guest L4 after any transformations": XPTI copies either the actual
guest L4 if not shadowed, or the shadow L4 (transformed) if shadowed.
Sketch: guest_get_eff_kern_l1e() has a pair of toggle_guest_pt() calls
which happen if the guest is in user mode. During live migration, a
log-dirty clean will do a domain_pause and then call
shadow_blow_tables(), unpinning the shadow of the guest user root
pagetable. After execution resumes, the first toggle_guest_pt() could
then cause that page to become unshadowed. The second
toggle_guest_pt() would then re-shadow it, possibly with a different
backing shadow page.
This is XSA-516 / CVE-2026-79609.
Fixes: 5784de3e20 ("x86: Meltdown band-aid against malicious 64-bit PV guests")
Assisted-by: Claude Code:claude-fable-5-1
Signed-off-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add a convenience target generating the compilation database from a
built object tree, alongside the other developer conveniences (tags,
cscope, cloc -- the last of which already walks the same .cmd files):
make -C xen compile_commands.json
The output lands in the object tree root. For an in-tree build,
clangd and other consumers discover it there automatically when
opening files; for an out-of-tree build, symlink it into the source
tree root (consumers search the ancestors of the file being edited).
Note the database records the compiler invocations actually used.
With a clang build it is consumable by clangd as-is; for a gcc build,
clang-based tools may need a small .clangd configuration
(CompileFlags: Remove/Add) dropping gcc-only flags.
Also add the generated file to .gitignore.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Two changes from the Linux original:
- Linux's compiler invocations end with the source file
("... -c -o foo.o foo.c"), and the script's line pattern relies
on that; Xen's cmd_cc_o_c places "-c $<" before "-o" and "-MQ",
so on a Xen object tree the unmodified script matches nothing and
produces an empty database. Adjust _LINE_PATTERN to capture the
command up to and including "-c" plus the source file, dropping
the remainder, which database consumers do not need.
- Reword the docstring and help text to refer to Xen.
The support for reading object lists from archives and modules.order
is unused in Xen but retained to minimise divergence from the
original.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
Xen's Kbuild-derived build system records the exact command line used
to compile each object in .<target>.o.cmd files. That is everything
needed to produce a compile_commands.json compilation database, the
format clangd and other tooling consume to provide accurate
cross-referencing (go to definition, find references, call hierarchy)
in LSP-capable editors.
Import scripts/clang-tools/gen_compile_commands.py from the Linux
kernel, unmodified, so that the provenance of the code is easy to
verify (commit 90efe2b9119f, Linux v6.16).
As-is the script produces an empty database on a Xen tree, since
Xen's compile command lines differ slightly from Linux's; the
following patch adapts it.
Assisted-by: LLM
Signed-off-by: George Dunlap <gwd@xenproject.org>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
George Dunlap