• Kai Huang's avatar
    KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest · 16a7fe37
    Kai Huang authored
    The new Asynchronous Exit (AEX) notification mechanism (AEX-notify)
    allows one enclave to receive a notification in the ERESUME after the
    enclave exit due to an AEX.  EDECCSSA is a new SGX user leaf function
    (ENCLU[EDECCSSA]) to facilitate the AEX notification handling.  The new
    EDECCSSA is enumerated via CPUID(EAX=0x12,ECX=0x0):EAX[11].
    
    Besides Allowing reporting the new AEX-notify attribute to KVM guests,
    also allow reporting the new EDECCSSA user leaf function to KVM guests
    so the guest can fully utilize the AEX-notify mechanism.
    
    Similar to existing X86_FEATURE_SGX1 and X86_FEATURE_SGX2, introduce a
    new scattered X86_FEATURE_SGX_EDECCSSA bit for the new EDECCSSA, and
    report it in KVM's supported CPUIDs.
    
    Note, no additional KVM enabling is required to allow the guest to use
    EDECCSSA.  It's impossible to trap ENCLU (without completely preventing
    the guest from using SGX).  Advertise EDECCSSA as supported purely so
    that userspace doesn't need to special case EDECCSSA, i.e. doesn't need
    to manually check host CPUID.
    
    The inability to trap ENCLU also means that KVM can't prevent the guest
    from using EDECCSSA, but that virtualization hole is benign as far as
    KVM is concerned.  EDECCSSA is simply a fancy way to modify internal
    enclave state.
    
    More background about how do AEX-notify and EDECCSSA work:
    
    SGX maintains a Current State Save Area Frame (CSSA) for each enclave
    thread.  When AEX happens, the enclave thread context is saved to the
    CSSA and the CSSA is increased by 1.  For a normal ERESUME which doesn't
    deliver AEX notification, it restores the saved thread context from the
    previously saved SSA and decreases the CSSA.  If AEX-notify is enabled
    for one enclave, the ERESUME acts differently.  Instead of restoring the
    saved thread context and decreasing the CSSA, it acts like EENTER which
    doesn't decrease the CSSA but establishes a clean slate thread context
    using the CSSA for the enclave to handle the notification.  After some
    handling, the enclave must discard the "new-established" SSA and switch
    back to the previously saved SSA (upon AEX).  Otherwise, the enclave
    will run out of SSA space upon further AEXs and eventually fail to run.
    
    To solve this problem, the new EDECCSSA essentially decreases the CSSA.
    It can be used by the enclave notification handler to switch back to the
    previous saved SSA when needed, i.e. after it handles the notification.
    Signed-off-by: default avatarKai Huang <kai.huang@intel.com>
    Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
    Acked-by: default avatarSean Christopherson <seanjc@google.com>
    Acked-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
    Link: https://lore.kernel.org/all/20221101022422.858944-1-kai.huang%40intel.com
    16a7fe37
cpuid.c 41.8 KB