[PATCH 00/14] x86: Address Space Isolation FPU preparations

Alejandro Vallejo posted 14 patches 4 days, 4 hours ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20241028154932.6797-1-alejandro.vallejo@cloud.com
xen/arch/x86/domctl.c             |  9 +++--
xen/arch/x86/hvm/emulate.c        | 10 ++++-
xen/arch/x86/hvm/hvm.c            |  8 ++--
xen/arch/x86/i387.c               | 67 ++++++++++++++++++++-----------
xen/arch/x86/include/asm/xstate.h | 29 +++++++++++--
xen/arch/x86/x86_emulate/blk.c    | 10 ++++-
xen/arch/x86/xstate.c             | 51 ++++++++++++++++-------
7 files changed, 130 insertions(+), 54 deletions(-)
[PATCH 00/14] x86: Address Space Isolation FPU preparations
Posted by Alejandro Vallejo 4 days, 4 hours ago
In a Xen build with Address Space Isolation the FPU state cannot come from the
xenheap, as that means the FPU state of vCPU_A may be speculatively accesible
from any pCPU running a hypercall on behalf of vCPU_B. This series prepares
code that manipulates the FPU state to use wrappers that fetch said state from
"elsewhere"[1]. Those wrappers will crystalise into something more than dummy
accesors after existing ASI efforts are merged. So far, they are:

  a) Remove the directmap (Elias El Yadouzi):
  https://lore.kernel.org/xen-devel/20240513134046.82605-1-eliasely@amazon.com/

    Removes all confidential data pages from the directmap and sets up the
    infrastructure to access them. Its trust boundary is the domain and builds
    the foundations of the secret hiding API around {un,}map_domain_page().

  b) x86: adventures in Address Space Isolation (Roger Pau Monne):
  https://lore.kernel.org/xen-devel/20240726152206.28411-1-roger.pau@citrix.com/

    Extends (a) to put the trust boundary at the vCPU instead so the threat
    model covers mutually distrustful vCPUs of the same domain. Extends the
    API for secret hiding to provide private pCPU-local resources. And an
    efficient means of accessing resources of the "current" vCPU.

In essence, the idea is to stop directly accessing a pointer in the vCPU
structure and instead collect it indirectly via a macro invocation. The
proposed API is a map/unmap pair in order to tame the complexity involved in
the various cases uniformly (Does the domain run with ASI enabled? Is the vCPU
"current"? Are we lazy-switching?).

The series is somewhat long, but each patch is fairly trivial. If need be, I
can fold back a lot of these onto single commits to make it shorter.

  * Patch 1 refreshes of a couple of asserts back into something helpful. Can
    be folded onto patches 12 and 13 if deemed too silly for a Fixes tag.

  * Patch 2 is the introduction of the wrappers in isolation.

  * Patches 3 - 10 are split for ease of review, but are conceptually the same
    thing over and over (to stop using direct v->arch.xsave_area and to use
    wrappers instead).

  * Patch 11 cleans the idle vcpu state after using it as dumping groung. It's
    not strictly required for this series, but I'm bound to forget to do it
    later after we _do_ care and does no harm to do it now. It's otherwise
    independent of the other patches (it clashes with 10, but only due to both
    modifying the same code; it's conceptually independent).

  * Patches 12 and 13 bite the bullet and enlightens the (f)xsave and (f)xrstor
    abstractions to use the wrappers rather than direct access.

  * Patches 14 is the last remaining direct use xsave area. It's too tricky to
    introduce ahead of patches 12 and 13 because they need state passed not
    available until those have gone in.

[1] That "elsewhere" will be with high likelihood either the directmap (on
non-ASI), some perma-mapped vCPU-local area (see series (b) at the top) or
implemented as a transient mapping in the style of {un,}map_domain_page() for
glacially cold accesses to non-current vCPUs. Importantly, writing the final
macros involve the other series going in.

Alejandro Vallejo (14):
  x86/xstate: Update stale assertions in fpu_x{rstor,save}()
  x86/xstate: Create map/unmap primitives for xsave areas
  x86/hvm: Map/unmap xsave area in hvm_save_cpu_ctxt()
  x86/fpu: Map/umap xsave area in vcpu_{reset,setup}_fpu()
  x86/xstate: Map/unmap xsave area in xstate_set_init() and
    handle_setbv()
  x86/hvm: Map/unmap xsave area in hvmemul_{get,put}_fpu()
  x86/domctl: Map/unmap xsave area in arch_get_info_guest()
  x86/xstate: Map/unmap xsave area in {compress,expand}_xsave_states()
  x86/emulator: Refactor FXSAVE_AREA to use wrappers
  x86/mpx: Map/unmap xsave area in in read_bndcfgu()
  x86/mpx: Adjust read_bndcfgu() to clean after itself
  x86/fpu: Pass explicit xsave areas to fpu_(f)xsave()
  x86/fpu: Pass explicit xsave areas to fpu_(f)xrstor()
  x86/xstate: Make xstate_all() and vcpu_xsave_mask() take explicit
    xstate

 xen/arch/x86/domctl.c             |  9 +++--
 xen/arch/x86/hvm/emulate.c        | 10 ++++-
 xen/arch/x86/hvm/hvm.c            |  8 ++--
 xen/arch/x86/i387.c               | 67 ++++++++++++++++++++-----------
 xen/arch/x86/include/asm/xstate.h | 29 +++++++++++--
 xen/arch/x86/x86_emulate/blk.c    | 10 ++++-
 xen/arch/x86/xstate.c             | 51 ++++++++++++++++-------
 7 files changed, 130 insertions(+), 54 deletions(-)

-- 
2.47.0