mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Andrew Cooper
422588e885
The current XPTI implementation isolates the directmap (and therefore a lot of guest data), but a large quantity of CPU0's state (including its stack) remains visible. Furthermore, an attacker able to read .text is in a vastly superior position to normal when it comes to fingerprinting Xen for known vulnerabilities, or scanning for ROP/Spectre gadgets. Collect together the entrypoints in .text.entry (currently 3x4k frames, but can almost certainly be slimmed down), and create a common mapping which is inserted into each per-cpu shadow. The stubs are also inserted into this mapping by pointing at the in-use L2. This allows stubs allocated later (SMP boot, or CPU hotplug) to work without further changes to the common mappings. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen-bugtool =========== The xen-bugtool command line application will collate the Xen dmesg output, details of the hardware configuration of your machine, information about the build of Xen that you are using, plus, if you allow it, various logs. The information collated can either be posted to a Xen Bugzilla bug (this bug must already exist in the system, and you must be a registered user there), or it can be saved as a .tar.bz2 for sending or archiving. The collated logs may contain private information, and if you are at all worried about that, you should not use this tool, or you should explicitly exclude those logs from the archive. xen-bugtool is wholly interactive, so simply run it, and answer the questions.