Commit 948e033031 ("automation/alpine: add elfutils-dev") had an unintended
consequence of causing Qemu to gain a runtime dependency on libdw.so
The {adl,zen3p}-pci-hvm-x86-64-gcc-debug tests, which are the only two tests
that run the built Qemu, started failing with:
Error loading shared library libdw.so.1: No such file or directory (needed by /usr/local/lib/xen/bin/qemu-system-i386)
Error relocating /usr/local/lib/xen/bin/qemu-system-i386: dwfl_begin: symbol not found
Update the test container with libelf to cope.
While editing the runtime dependency list, fix up two other problems. texinfo
isn't a runtime dependency, and we should be using xz itself, not it's
development libraries. Both changes shrink the initrd used for tests.
Fixes: 948e033031 ("automation/alpine: add elfutils-dev")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
With all architectures no longer wanting an image name in the command line
handling, drop the parameter and forgo making one up.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
The differences between inline, __inline and __inline__ keywords (as far as
GCC is concenred at least) are a vestigial remnant of older C standards, and
in Xen we use inline almost exclusively.
Replace __inline and __inline__ with regular inline, and remove their
exceptions from the MISRA configuration.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Simone Ballarin <simone.ballarin@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The codebase is now -Wwrite-strings clean. Activate the option to cause
string literals to have a const type, and prevent any violations of MISRA Rule
7.4 being reintroduced.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
-Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but this
logic looks incorrect. It was inherited from the x86 side, where the logic
was redundant and has now been removed.
In the ARM case it inserts the image name into "xen,xen-bootargs" and there is
no logic at all to strip this before parsing it as the command line.
The absence of any logic to strip an image name suggests that it shouldn't
exist there, or having a Xen image named e.g. "hmp-unsafe" in the filesystem
is going to lead to some unexpected behaviour on boot.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <jgrall@amazon.com>
-Wwrite-strings is unhappy with assigning "xen" to a mutable pointer, but all
this work is useless; it's just prepending the image name which cmdline_cook()
intentionally strips back out (and allocating memory to do so).
Simply forgo the work and identify EFI_LOADER as one of the loaders which
doesn't prepend the image name.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Rework the logic in __start_xen() to not potentially pass NULL into
cmdline_cook(). This makes the logic easier to follow too, and the rest of
__start_xen() is safe when initialising cmdline to the empty string.
Update cmdline_cook() to take and return const pointers, and write a
description of what it does. It now requires a non-NULL input and guarentees
to return a pointer somewhere in the 'p' string.
Note this only compiles because strstr() launders the const off the pointer
when assigning to the mutable kextra, but that logic only mutates the
mbi->cmdline buffer.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There's a confusing mix of variables; a static dom0_cmdline[], and a cmdline
pointer which points to image->string before being pointed at the static
buffer in order to be passed into construct_dom0(). cmdline being a mutable
pointer falls over -Wwrite-strings builds.
Delete the cmdline pointer, and rename dom0_cmdline[] to cmdline extending it
to have full function scope.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
GCC complains:
arch/arm/platforms/brcm.c: In function ‘brcm_populate_plat_regs’:
arch/arm/platforms/brcm.c:76:27: error: passing argument 1 of ‘brcm_get_dt_node’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
76 | rc = brcm_get_dt_node("brcm,brcmstb-cpu-biu-ctrl", &node, ®_base);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
and
arch/arm/platforms/exynos5.c: In function ‘exynos5_smp_init’:
arch/arm/platforms/exynos5.c:109:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
109 | compatible = "samsung,exynos4210-sysram-ns";
| ^
arch/arm/acpi/domain_build.c: In function 'acpi_create_xsdt':
./include/acpi/actbl.h:66:33: error: passing argument 3 of 'acpi_xsdt_modify_entry' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
66 | #define ACPI_SIG_FADT "FACP" /* Fixed ACPI Description Table */
| ^~~~~~
In all cases, just make the relevant variable const.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
GCC complains:
drivers/char/arm-uart.c: In function 'dt_uart_init':
drivers/char/arm-uart.c:81:17: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
81 | options = "";
| ^
The problem is using the options string for both splitting opt_duart, and to
hold a token "" for no options.
Use two variables; one mutable and one const.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
No more users.
This completes the work started in commit 9202342594 ("xen/build: Use C99
booleans"), July 2016.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... as part of cleaning up the types used. Minor style and/or MISRA cleanup
on some altered lines.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
... as part of cleaning up the types used. Minor style cleanup on some
altered lines.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The MP spec requires a minimum of 1k alignment. So too does Xen's use of a
single fixmap page to map the IO-APIC.
Reject out-of-spec values so we don't end up in a position where a bad
firmware value causes Xen to use the wrong mapping.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
sysenter_eflags_saved() and int80_direct_trap() are now only used by a single
translation unit. Move the declarations into the respective traps.c, renaming
int80_direct_trap() to entry_int80() to match the style elsewhere.
Annotate all 3 with nocall like all other entry paths.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is a micro-optimsiation for Silvermont microarchitectures, which don't
recognise the 64bit form as a zeroing idiom.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There is no such thing as a fastpath with a printk() on it, making printk() an
excellent heuristic for slowpaths.
Net delta is:
add/remove: 595/2 grow/shrink: 56/762 up/down: 70879/-87331 (-16452)
Total: Before=4085425, After=4068973, chg -0.40%
because cold functions are optimised differently. For example, one function
with a particularly large swing is:
vmcs_dump_vcpu.cold - 2172 +2172
vmcs_dump_vcpu 7030 408 -6622
with a net delta of 7030 down to 4450.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Prior to commit 9cd7e31b3f ("xen/iommu: cleanup iommu related domctl
handling"), when CONFIG_GDBSX was compiled out, iommu_do_domctl() fell over a
NULL pointer. One of several bugs here is known-but-compiled-out subops
falling into the default chain and hitting unrelated logic.
Remove the CONFIG_GDBSX ifdefary in arch_do_domctl() by implementing
gdbsx_domctl() and moving the logic across.
As minor cleanup,
* gdbsx_guest_mem_io() can become static
* Remove opencoding of domain_vcpu() and %pd
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Before speculation defences, some paths in Xen could genuinely get away with
being IRQs-on at entry. But XPTI invalidated this property on most paths, and
attempting to maintain it on the remaining paths was a mistake.
Fast forward, and DO_SPEC_CTRL_COND_IBPB (protection for AMD BTC/SRSO) is not
IRQ-safe, running with IRQs enabled in some cases. The other actions taken on
these paths happen to be IRQ-safe.
Make entry_int82() and int80_direct_trap() unconditionally Interrupt Gates
rather than Trap Gates. Remove the conditional re-adjustment of
int80_direct_trap() in smp_prepare_cpus(), and have entry_int82() explicitly
enable interrupts when safe to do so.
In smp_prepare_cpus(), with the conditional re-adjustment removed, the
clearing of pv_cr3 is the only remaining action gated on XPTI, and it is out
of place anyway, repeating work already done by smp_prepare_boot_cpu(). Drop
the entire if() condition to avoid leaving an incorrect vestigial remnant.
Also drop comments which make incorrect statements about when its safe to
enable interrupts.
This is XSA-446 / CVE-2023-46836
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
sphinx-build reports:
docs/designs/launch/hyperlaunch.rst: WARNING: document isn't included in any toctree
docs/designs/launch/hyperlaunch-devicetree.rst: WARNING: document isn't included in any toctree
docs/misc/xen-makefiles/makefiles.rst: WARNING: document isn't included in any toctree
docs/misra/C-language-toolchain.rst: WARNING: document isn't included in any toctree
docs/misra/C-runtime-failures.rst: WARNING: document isn't included in any toctree
docs/misra/documenting-violations.rst: WARNING: document isn't included in any toctree
docs/misra/exclude-list.rst: WARNING: document isn't included in any toctree
docs/misra/xen-static-analysis.rst: WARNING: document isn't included in any toctree
Create an up-to-date index.rst in misra/ create an "unsorted docs" section at
the top level to contain everything else. They can be re-filed at a later
date.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
sphinx-build reports:
docs/misra/exclude-list.rst:47: WARNING: Unexpected indentation.
docs/misra/exclude-list.rst:50: WARNING: Inline emphasis start-string without end-string.
Nested lists require newlines as delimiters, and * either needs escaping, or
put in a literal block.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
sphinx-build reports:
docs/designs/launch/hyperlaunch.rst:111: WARNING: Title underline too short.
docs/designs/launch/hyperlaunch.rst:203: WARNING: Unexpected indentation.
docs/designs/launch/hyperlaunch.rst:216: WARNING: Unexpected indentation.
Nested lists require newlines as delimiters.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
These 3 Kconfig docs were imported from Linux erroneously. They are
GPL-2.0-only in Linux, but have no SPDX tag and were placed in such a way to
be included by the blanket statement saying that all RST files are CC-BY-4.0.
We should not be carrying a shadow copy of these docs. They aren't even wired
into our Sphinx docs, and anyone wanting to refer to Kconfig docs is going to
look at the Linux docs anyway. These, and more docs can be found at:
https://www.kernel.org/doc/html/latest/kbuild/
which also have corrections vs the snapshot we took.
Fixes: f80fe2b34f ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Two files are missing SDPX tags, but are covered by the blanketing license
statement in docs/README.sources saying that RST files are CC-BY-4.0
Fixes: 3c911be55f ("docs/misra: document the C dialect and translation toolchain assumptions.")
Fixes: 7211904e09 ("docs/misra: add documentation skeleton for MISRA C:2012 Dir 4.1")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
As reported:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in arch/x86/time.c:1542:32
(XEN) member access within null pointer of type 'union vcpu_info_t'
(XEN) ----[ Xen-4.19-unstable x86_64 debug=y ubsan=y Not tainted ]----
...
(XEN) Xen call trace:
(XEN) [<ffff82d040345036>] R common/ubsan/ubsan.c#ubsan_epilogue+0xa/0xd2
(XEN) [<ffff82d0403456e8>] F __ubsan_handle_type_mismatch+0x133/0x49b
(XEN) [<ffff82d040345b4a>] F __ubsan_handle_type_mismatch_v1+0xfa/0xfc
(XEN) [<ffff82d040623356>] F arch/x86/time.c#__update_vcpu_system_time+0x212/0x30f
(XEN) [<ffff82d040623461>] F update_vcpu_system_time+0xe/0x10
(XEN) [<ffff82d04062389d>] F arch/x86/time.c#local_time_calibration+0x1f7/0x523
(XEN) [<ffff82d0402a64b5>] F common/softirq.c#__do_softirq+0x1f4/0x31a
(XEN) [<ffff82d0402a67ad>] F do_softirq+0x13/0x15
(XEN) [<ffff82d0405a95dc>] F arch/x86/domain.c#idle_loop+0x2e0/0x367
(XEN)
(XEN) ================================================================================
GCC 10 at least doesn't consider it valid to derive a pointer from vcpu_info()
prior to checking that the underlying map pointer is good.
Reorder actions so the map pointer is checked first.
Fixes: 20279afd73 ("x86: split populating of struct vcpu_time_info into a separate function")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
MISRA doesn't like !!CONST being used in place of a 1 (Rule 10.1). Update the
expression to just be a plain 1, which still matches the description.
No functional change.
Reported-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Collect all x86 and ARM changes together instead of having them scattered.
Tweak grammar as necessary.
No change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Henry Wang <Henry.Wang@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Make the command line docs match the actual implementation, and state that the
default behaviour is selected at compile time.
Fixes: 980d6acf15 ("IOMMU: make DMA containment of quarantined devices optional")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
The use of access_ok() is buggy, because it permits access to the compat
translation area. 64bit PV guests don't use the XLAT area, but on AMD
hardware, the DBEXT feature allows a breakpoint to match up to a 4G aligned
region, allowing the breakpoint to reach outside of the XLAT area.
Prior to c/s cda16c1bb2 ("x86: mirror compat argument translation area for
32-bit PV"), the live GDT was within 4G of the XLAT area.
All together, this allowed a malicious 64bit PV guest on AMD hardware to place
a breakpoint over the live GDT, and trigger a #DB livelock (CVE-2015-8104).
Introduce breakpoint_addr_ok() and explain why __addr_ok() happens to be an
appropriate check in this case.
For Xen 4.14 and later, this is a latent bug because the XLAT area has moved
to be on its own with nothing interesting adjacent. For Xen 4.13 and older on
AMD hardware, this fixes a PV-trigger-able DoS.
This is part of XSA-444 / CVE-2023-34328.
Fixes: 65e3554908 ("x86/PV: support data breakpoint extension registers")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The handling of MSR_DR{0..3}_MASK is asymmetric between PV and HVM guests.
HVM guests context switch in based on the guest view of DBEXT, whereas PV
guest switch in base on the host capability. Both guest types leave the
context dirty for the next vCPU.
This leads to the following issue:
* PV or HVM vCPU has debugging active (%dr7 + mask)
* Switch out deactivates %dr7 but leaves other state stale in hardware
* HVM vCPU with debugging activate but can't see DBEXT is switched in
* Switch in loads %dr7 but leaves the mask MSRs alone
Now, the HVM vCPU is operating in the context of the prior vCPU's mask MSR,
and furthermore in a case where it genuinely expects there to be no masking
MSRs.
As a stopgap, adjust the HVM path to switch in/out the masks based on host
capabilities rather than guest visibility (i.e. like the PV path). Adjustment
of the of the intercepts still needs to be dependent on the guest visibility
of DBEXT.
This is part of XSA-444 / CVE-2023-34327
Fixes: c097f54912 ("x86/SVM: support data breakpoint extension registers")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
We long ago fixed the emulator to not inject exceptions behind our back.
Therefore, assert that that a PV event (including interrupts, because that
would be buggy too) isn't pending, rather than skipping the #DB injection if
one is.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Nicola reports that the XSA-438 fix introduced new MISRA violations because of
some incidental tidying it tried to do. The parameter is useless, so resolve
the MISRA regression by removing it.
hap_update_cr3() discards the parameter entirely, while sh_update_cr3() uses
it to distinguish internal and external callers and therefore whether the
paging lock should be taken.
However, we have paging_lock_recursive() for this purpose, which also avoids
the ability for the shadow internal callers to accidentally not hold the lock.
Fixes: fb0ff49fe9 ("x86/shadow: defer releasing of PV's top-level shadow reference")
Reported-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
It is unconditionally 0 in Xen, and was deleted in Linux somewhere between 2.5
and 2.6.
Remove it in Xen too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
In the Zen1 microarchitecure, there is one divider in the pipeline which
services uops from both threads. In the case of #DE, the latched result from
the previous DIV to execute will be forwarded speculatively.
This is an interesting covert channel that allows two threads to communicate
without any system calls. In also allows userspace to obtain the result of
the most recent DIV instruction executed (even speculatively) in the core,
which can be from a higher privilege context.
Scrub the result from the divider by executing a non-faulting divide. This
needs performing on the exit-to-guest paths, and ist_exit-to-Xen.
Alternatives in IST context is believed safe now that it's done in NMI
context.
This is XSA-439 / CVE-2023-20588.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We already have 3 cases using STIBP as a Zen1/2 heuristic, and are about to
introduce a 4th. Wrap the heuristic into a pair of predicates rather than
opencoding it, and the explanation of the heuristic, at each usage site.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There is a corner case where e.g. an NMI hitting an exit-to-guest path after
SPEC_CTRL_EXIT_TO_* would have run the entire NMI handler *after* the VERW
flush to scrub potentially sensitive data from uarch buffers.
In order to compensate, issue VERW when exiting to Xen from an IST entry.
SPEC_CTRL_EXIT_TO_XEN already has two reads of spec_ctrl_flags off the stack,
and we're about to add a third. Load the field into %ebx, and list the
register as clobbered.
%r12 has been arranged to be the ist_exit signal, so add this as an input
dependency and use it to identify when to issue a VERW.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use %r12 to hold an ist_exit boolean. This register is zero elsewhere in the
entry/exit asm, so it only needs setting in the IST path.
As this is subtle and fragile, add check_ist_exit() to be used in debugging
builds to cross-check that the ist_exit boolean matches the entry vector.
Write check_ist_exit() it in C, because it's debug only and the logic more
complicated than I care to maintain in asm.
For now, we only need to use this signal in the exit-to-Xen path, but some
exit-to-guest paths happen in IST context too. Check the correctness in all
exit paths to avoid the logic bit-rotting.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
All other SPEC_CTRL_{ENTRY,EXIT}_* helpers hold stack_end in %r14. Adjust it
for consistency.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... to better explain how they're used.
Doing so highlights that SPEC_CTRL_EXIT_TO_XEN is missing a VERW flush for the
corner case when e.g. an NMI hits late in an exit-to-guest path.
Leave a TODO, which will be addressed in subsequent patches which arrange for
VERW flushing to be safe within SPEC_CTRL_EXIT_TO_XEN.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These have grown more complex over time, with some already having been
converted.
Provide full Requires/Clobbers comments, otherwise missing at this level of
indirection.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
With the SPEC_CTRL_EXIT_TO_XEN{,_IST} confusion fixed, it's now obvious that
there's only a single EXIT_TO_XEN path. Fold DO_SPEC_CTRL_EXIT_TO_XEN into
SPEC_CTRL_EXIT_TO_XEN to simplify further fixes.
When merging labels, switch the name to .L\@_skip_sc_msr as "skip" on its own
is going to be too generic shortly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
c/s 3fffaf9c13 ("x86/entry: Avoid using alternatives in NMI/#MC paths")
dropped the only user, leaving behind the (incorrect) implication that Xen had
split exit paths.
Delete the unused SPEC_CTRL_EXIT_TO_XEN and rename SPEC_CTRL_EXIT_TO_XEN_IST
to SPEC_CTRL_EXIT_TO_XEN for consistency.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
RTM debugging and BusLock Detect have both introduced conditional behaviour
into the %dr6/7 calculations which Xen's existing logic doesn't account for.
Introduce the CPUID bit for BusLock Detect, so we can get the %dr6 behaviour
correct from the outset.
Implement x86_adj_dr{6,7}_rsvd() fully, and use them in place of the plain
bitmasks.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Broken out of the subsequent patch for clarity.
Add stub x86_adj_dr{6,7}_rsvd() functions which will be extended in the
following patch to fix bugs, and adjust debugreg.h to compile with a more
minimal set of includes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Right now, bad PV state is silently dropped and zeroed, while bad HVM state is
passed directly to hardware and can trigger VMEntry/VMRUN failures. e.g.
(XEN) d12v0 vmentry failure (reason 0x80000021): Invalid guest state (0)
...
(XEN) RFLAGS=0x00000002 (0x00000002) DR7 = 0x4000000000000001
Furthermore, prior to c/s 30f43f4aa8 ("x86: Reorganise and rename debug
register fields in struct vcpu") in Xen 4.11 where v->arch.dr6 was reduced in
width, the toolstack can cause a host crash by loading a bad %dr6 value on
VT-x hardware.
Reject any %dr6/7 values with upper bits set. For PV guests, also audit
%dr0..3 using the same logic as in set_debugreg() so they aren't silently
zeroed later in the function. Leave a comment behind explaing how %dr4/5
handling changed, and why they're ignored now.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... as part of cleaning up the types used. Minor style cleanup on some
altered lines.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
None of the mercurial metadata has been updated since around Xen 4.2, making
them more than a decade stale.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
At the time of XSA-170, the x86 instruction emulator was genuinely broken. It
would load arbitrary values into %rip and putting a check here probably was
the best stopgap security fix. It should have been reverted following c/s
81d3a0b26c "x86emul: limit-check branch targets" which corrected the emulator
behaviour.
However, everyone involved in XSA-170, myself included, failed to read the SDM
correctly. On the subject of %rip consistency checks, the SDM stated:
If the processor supports N < 64 linear-address bits, bits 63:N must be
identical
A non-canonical %rip (and SSP more recently) is an explicitly legal state in
x86, and the VMEntry consistency checks are intentionally off-by-one from a
regular canonical check.
The consequence of this bug is that Xen will currently take a legal x86 state
which would successfully VMEnter, and corrupt it into having non-architectural
behaviour.
Furthermore, in the time this bugfix has been pending in public, I
successfully persuaded Intel to clarify the SDM, adding the following
clarification:
The guest RIP value is not required to be canonical; the value of bit N-1
may differ from that of bit N.
Fixes: ffbbfda377 ("x86/VMX: sanitize rIP before re-entering guest")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
As the Alpine 3.18 container notes:
egrep: warning: egrep is obsolescent; using grep -E
Adjust it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Clang-15 complains:
tcgbios.c:598:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
void tcpa_calling_int19h()
^
void
C2x formally removes K&R syntax. The declarations for these functions in
32bitprotos.h are already ANSI compatible. Update the definitions to match.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
GCC 12 objects to pointers derived from a constant:
util.c: In function 'find_rsdp':
util.c:429:16: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
429 | ebda_seg = *(uint16_t *)ADDR_FROM_SEG_OFF(0x40, 0xe);
cc1: all warnings being treated as errors
This is a GCC bug, but work around it rather than turning array-bounds
checking off generally.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
GDS_CTRL is introduced by the August 2023 microcode. GDS_NO is for current
and future processors not susceptible to GDS.
This is part of XSA-435 / CVE-2022-40982
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The August 2023 microcode for GDS has an impact on the CLWB instruction. See
code comments for full details.
This is part of XSA-435 / CVE-2022-40982
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
On native, synthesise the SRSO bits by probing various hardware properties as
given by AMD.
Extend the IBPB-on-entry mitigations to Zen3/4 CPUs. There is a microcode
prerequisite to make this an effective mitigation.
This is part of XSA-434 / CVE-2023-20569
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
AMD have specified new CPUID bits relating to SRSO.
* SRSO_NO indicates that hardware is no longer vulnerable to SRSO.
* IBPB_BRTYPE indicates that IBPB flushes branch type information too.
* SBPB indicates support for a relaxed form of IBPB that does not flush
branch type information.
Current CPUs (Zen4 and older) are not expected to enumerate these bits.
Native software is expected to synthesise them for guests using model and
microcode revision checks.
Two are just status bits, and SBPB is trivial to support for guests by
tweaking the reserved bit calculation in guest_wrmsr() and feature
dependencies. Expose all by default to guests, so they start showing up when
Xen synthesises them.
While adding feature dependenies for IBPB, fix up an overlooked issue from
XSA-422. It's inappropriate to advertise that IBPB flushes RET predictions if
IBPB is unavailable itself.
This is part of XSA-434 / CVE-2023-20569
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
... in order to make the SRSO mitigations easier to integrate.
* Check for AMD/Hygon CPUs directly, rather than assuming based on IBPB.
In particular, Xen supports synthesising the IBPB bit to guests on Intel to
allow IBPB while dissuading the use of (legacy) IBRS.
* Collect def_ibpb_entry rather than opencoding the BTC_NO calculation for
both opt_ibpb_entry_{pv,hvm}.
No functional change.
This is part of XSA-434 / CVE-2023-20569
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
The opensuse-tumbleweed build jobs currently fail with:
/builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.c: In function 'rsa_private':
/builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.c:56:7: error: the comparison will always evaluate as 'true' for the address of 'p' will never be NULL [-Werror=address]
56 | if (!key->p || !key->q || !key->u) {
| ^
In file included from /builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.c:17:
/builds/xen-project/xen/stubdom/tpm_emulator-x86_64/crypto/rsa.h:28:12: note: 'p' declared here
28 | tpm_bn_t p;
| ^
This is because all tpm_bn_t's are 1-element arrays (of either a GMP or
OpenSSL BIGNUM flavour).
Adjust it to compile. No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
This option is particularly dubious as Xen does not use Protection Keys, owing
to the sharing of pagetables with PV guests. All this option does is hide PKU
by default from HVM guests, and is therefore redundant with the more generic
cpuid=no-pku.
The variable ought to be in __initdata given it's single user, but deleting it
entirely looks to be a better course of action.
Visibility of PKU to guests should be handled via its vm.cfg file.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Henry Wang <Henry.Wang@arm.com>
Add the script to the X86 section in ./MAINTAINERS.
Structures or unions without any named members aren't liked by Misra
(nor the C standard). Avoid emitting such for leaves without any known
bits.
The placeholders are affected similarly, but are only visible to MISRA in the
middle of a patch series adding a new leaf. The absence of a name was
intentional as these defines need to not duplicate names.
As that's not deemed acceptable any more, move placeholder processing into the
main loop and append the the word number to generate unique names.
$ diff cpuid-autogen-{before,after}.h
@@ -1034,7 +1034,7 @@
bool intel_psfd:1, ipred_ctrl:1, rrsba_ctrl:1, ddp_ctrl:1, ...
#define CPUID_BITFIELD_14 \
- bool :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, ...
+ uint32_t _placeholder_14
#define CPUID_BITFIELD_15 \
bool :1, :1, :1, :1, avx_vnni_int8:1, avx_ne_convert:1, :1, ...
@@ -1043,19 +1043,19 @@
bool rdcl_no:1, eibrs:1, rsba:1, skip_l1dfl:1, intel_ssb_no:1, ...
#define CPUID_BITFIELD_17 \
- bool :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, :1, ...
+ uint32_t _placeholder_17
#define CPUID_BITFIELD_18 \
- uint32_t :32 /* placeholder */
+ uint32_t _placeholder_18
#define CPUID_BITFIELD_19 \
- uint32_t :32 /* placeholder */
+ uint32_t _placeholder_19
#define CPUID_BITFIELD_20 \
- uint32_t :32 /* placeholder */
+ uint32_t _placeholder_20
#define CPUID_BITFIELD_21 \
- uint32_t :32 /* placeholder */
+ uint32_t _placeholder_21
#endif /* __XEN_X86__FEATURESET_DATA__ */
No functional change.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is used in an assertion only, which is somewhat dubious to begin with and
isn't expected to surivive the x86-S work (where TR is expected to become
become be a NUL selector).
Delete it now. This avoids many cases where as a global symbol, it shadows
local string variables.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
This makes the names match the architectural short names that we use
elsewhere. This avoids 'debug' in particular from being a global symbol
shadowed by many local parameter names.
Remove the DECLARE_TRAP_HANDLER{,_CONST}() infrastructure. Only NMI/#MC are
referenced externally (and NMI will cease to be soon, as part of adding FRED
support). Move the entrypoint declarations into the respective traps.c where
they're used, rather than keeping them visible across ~all of Xen.
Drop the long-stale comment at the top of init_idt_traps(). It's mostly
discussing a 32bit Xen, and bogus otherwise as it's impossible to use trap
gates correctly for these purposes.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
... in order to clean up the declarations without needing to forward declare
it for handle_gdt_ldt_mapping_fault()
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This line:
val &= ~chickenbit;
ends up truncating val to 32 bits, and turning off various errata workarounds
in Zen2 systems.
Fixes: f91c5ea970 ("x86/amd: Mitigations for Zenbleed")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
With hvm_copy_to_guest_*() able to use const sources, update construct_dom0()
and friends to pass a const cmdline pointer. Nothing in these paths have a
reason to be modifying the command line passed in.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This hunk was accidentally missing from a previous change.
Fixes: d642c07066 ("xen/x86: Use const char * for string literals")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The work to fix MISRA rule 7.4 (using mutable pointers to string literals)
identifies that string literals do indeed get passed into
hvm_copy_to_guest_linear() by way of the PVH dom0 command line.
This higlights that the copy_to_* helpers really ought to take a const
source. Update the function types to match, and cast away constness in the
wrappers around __hvm_copy() where HVMCOPY_to_guest is used.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This global variable is shadowed by plenty local variables, violating MISRA
rule 5.3. Some architectures happen to have a symbol by the name of start in
their head.S's, but it's not a useful symbol to reference from C.
In fact, the single use of the global start[] in RISC-V means to use _start[]
as the linker symbol at the beginning of the .text section, not the function
which happens to be in the same location.
Fix RISC-V to use the right symbol for it's calculation, and drop the extern.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
With xl/libxl now able to control the policy bits for MSR_ARCH_CAPS, it is
safe to advertise to guests by default. In turn, we don't need the special
case to expose details to dom0.
This advertises MSR_ARCH_CAPS to guests on *all* Intel hardware, even if the
register content ends up being empty.
- Advertising ARCH_CAPS and not RSBA signals "retpoline is safe here and
everywhere you might migrate to". This is important because it avoids the
guest kernel needing to rely on model checks.
- Alternatively, levelling for safety across the Broadwell/Skylake divide
requires advertising ARCH_CAPS and RSBA, meaning "retpoline not safe on
some hardware you might migrate to".
On Cascade Lake and later hardware, guests can now see RDCL_NO (not vulnerable
to Meltdown) amongst others. This causes substantial performance
improvements, as guests are no longer applying software mitigations in cases
where they don't need to.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Zenbleed is a malfunction on AMD Zen2 uarch parts which results in corruption
of the vector registers. An attacker can trigger this bug deliberately in
order to access stale data in the physical vector register file. This can
include data from sibling threads, or a higher-privilege context.
Microcode is the preferred mitigation but in the case that's not available use
the chickenbit as instructed by AMD. Re-evaluate the mitigation on late
microcode load too.
This is XSA-433 / CVE-2023-20593.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
There are no callers, and the non-stub implementation is #if 0'd out, with the
internal trying to perform an AML invocation.
There's no plausible way that code is getting un-#if 0'd, so drop it.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Typedef-ing a naked pointer like this is an anti-pattern which is best
avoided. Furthermore, it's problematic to pass a string literal in a mutable
type. Delete the type entirely, and replace it with a plain 'const char *'.
This highlights two further bugs. acpi_get_table() already had a mismatch in
types between it's declaration and definition, and we have declarations for
acpi_get_handle() and acpi_get_table_header() but no definition at all, nor
any callers.
This fixes violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
and of Rule 8.3:
All declarations of an object or function shall use the same names and type
qualifiers.
and of Rule 8.6:
An identifier with external linkage shall have exactly one external
definition.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an object unless the object's type
is "pointer to const-qualified char".
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Xen uses the stdint types. Rearrange the types headers to define the
compatibility __{u,s}$N types in terms of the stdint types, not the other way
around.
All supported compilers on architectures other than x86 support the stdint
__*_TYPE__ macros. Move these into a new xen/stdint.h to avoid them being
duplicated in each architecture. For the very old x86 compilers, synthesize
suitable types using GCC internals.
This cleanup has the side effect of removing all use of the undocumented
__signed__ GCC keyword. This is a vestigial remnant of `gcc -traditional`
mode for dialetcs of C prior to the introduction of the signed keyword.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
We're about to rearrange the common and arch types.h split. While most
users already include <xen/types.h>, a few do not and some files fail to
compile as a result.
Almost all logic is going to have types very early in the include chain. Drop
the include entirely from C files, and swap to the common types.h in headers.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
It was previously noted that CALL/BUG is a weird combination, but there is
good reason to use this pattern.
Introduce an explicit tailcall macro make it clearer in context.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This should be static, and there's no need for a separate (non-init, even)
function to perform a simple equality test. Drop the is_ prefix which is
gramatically questionable, and make it __ro_after_init.
Leave a TODO, because the behaviour is definitely wrong to be applied to all
modern Intel CPUs. The question has been raised on xen-devel previously
without conclusion.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In particular, the libxg wrapper for unxz.c uses char for bool_t which is a
major antipattern. Luckily the code doesn't suffer from truncated values.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
These aren't used, and are not obvious useful either.
tools/ does have some logic which works on $(XEN_OS) directly, and some on
CONFIG_$(XEN_OS) too, but this isn't how we typically refer to things.
The only user ever of this scheme (AFAICT) was introduced in
c0fd920e98 (2006) and deleted in fa2244104b (2010).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Jiamei Xie <jiamei.xie@arm.com>
Andrew Cooper