docs/guest-guide: Discuss when not use a hypercall page

The Linux rethunk and safe-ret speculative safety techniques involve
transforming `ret` to `jmp __x86_return_thunk` at compile time.  Placing naked
`ret`s back in executable .text breaks these mitigations.

CET-IBT requires ENDBR instructions, and while we could in principle fix that,
the need to select between ENDBR32 or ENDBR64 means that the contents of the
hypercall page would need to become more mode-specific than it currently
is (HVM hypercall pages are currently 32bit and 64bit compatbile).  However,
there's no feasible way to make a hypercall page compatible with fine-grain
CFI schemes such as FineIBT.

OSes which care about either of these things are better off avoiding the
hypercall page.

This is part of XSA-466.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

diff --git a/docs/guest-guide/x86/hypercall-abi.rst b/docs/guest-guide/x86/hypercall-abi.rst
index 8004122ca49d2404a4923b2cbb2e0a1fb2a1fb78..745fbbb64a267a756dfa9dd902c2537acf5d28b9 100644 (file)
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -82,6 +82,13 @@ The hypercall page is a page of guest RAM into which Xen will write suitable
 transfer stubs.  It is intended as a convenience for guests, but use of the
 hypercall page is not mandatory for making hypercalls to Xen.
 
+.. note::
+
+   There are cases where a hypercall page should not be used.  It contains
+   ``ret`` instructions which are not compatible with certain speculative
+   security techniques, and it does not contain ``endbr`` instructions which
+   are necessary for certain Control-flow Integrity schemes.
+
 Creating a hypercall page is an isolated operation from Xen's point of view.
 It is the guests responsibility to ensure that the hypercall page, once
 written by Xen, is mapped with executable permissions so it may be used.