Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
“5f25e3fd065f7e7cfde608fc3bfa399160afaaf6”上不存在“projects/TheRamU/imports.yml”
切换分支/标签
  1. 20 9月, 2022 14 次提交
  3. 01 9月, 2022 1 次提交
  5. 17 8月, 2022 1 次提交
  7. 04 8月, 2022 5 次提交
  9. 19 7月, 2022 1 次提交
    • S
      KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded · 85fc72e3
      由 Sean Christopherson 提交于 
      stable inclusion
from stable-v5.10.112
commit 342454231ee5f2c2782f5510cab2e7a968486fef
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5HL0X

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=342454231ee5f2c2782f5510cab2e7a968486fef

--------------------------------

commit 1d0e8480 upstream.

Resolve nx_huge_pages to true/false when kvm.ko is loaded, leaving it as
-1 is technically undefined behavior when its value is read out by
param_get_bool(), as boolean values are supposed to be '0' or '1'.

Alternatively, KVM could define a custom getter for the param, but the
auto value doesn't depend on the vendor module in any way, and printing
"auto" would be unnecessarily unfriendly to the user.

In addition to fixing the undefined behavior, resolving the auto value
also fixes the scenario where the auto value resolves to N and no vendor
module is loaded.  Previously, -1 would result in Y being printed even
though KVM would ultimately disable the mitigation.

Rename the existing MMU module init/exit helpers to clarify that they're
invoked with respect to the vendor module, and add comments to document
why KVM has two separate "module init" flows.

  =========================================================================
  UBSAN: invalid-load in kernel/params.c:320:33
  load of value 255 is not a valid value for type '_Bool'
  CPU: 6 PID: 892 Comm: tail Not tainted 5.17.0-rc3+ #799
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x34/0x44
   ubsan_epilogue+0x5/0x40
   __ubsan_handle_load_invalid_value.cold+0x43/0x48
   param_get_bool.cold+0xf/0x14
   param_attr_show+0x55/0x80
   module_attr_show+0x1c/0x30
   sysfs_kf_seq_show+0x93/0xc0
   seq_read_iter+0x11c/0x450
   new_sync_read+0x11b/0x1a0
   vfs_read+0xf0/0x190
   ksys_read+0x5f/0xe0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   </TASK>
  =========================================================================

Fixes: b8e8c830 ("kvm: mmu: ITLB_MULTIHIT mitigation")
Cc: stable@vger.kernel.org
Reported-by: NBruno Goncalves <bgoncalv@redhat.com>
Reported-by: NJan Stancek <jstancek@redhat.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Message-Id: <20220331221359.3912754-1-seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
      85fc72e3
  11. 18 7月, 2022 2 次提交
  13. 08 7月, 2022 12 次提交
    • S
      KVM: x86: Fix implicit enum conversion goof in scattered reverse CPUID code · 90772c12
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 462f8dde
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 462f8dde KVM: x86: Fix implicit enum conversion
goof in scattered reverse CPUID code.
Backport for SGX virtualization support

--------------------------------

Take "enum kvm_only_cpuid_leafs" in scattered specific CPUID helpers
(which is obvious in hindsight), and use "unsigned int" for leafs that
can be the kernel's standard "enum cpuid_leaf" or the aforementioned
KVM-only variant.  Loss of the enum params is a bit disapponting, but
gcc obviously isn't providing any extra sanity checks, and the various
BUILD_BUG_ON() assertions ensure the input is in range.

This fixes implicit enum conversions that are detected by clang-11:

arch/x86/kvm/cpuid.c:499:29: warning: implicit conversion from enumeration type 'enum kvm_only_cpuid_leafs' to different enumeration type 'enum cpuid_leafs' [-Wenum-conversion]
        kvm_cpu_cap_init_scattered(CPUID_12_EAX,
        ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~
arch/x86/kvm/cpuid.c:837:31: warning: implicit conversion from enumeration type 'enum kvm_only_cpuid_leafs' to different enumeration type 'enum cpuid_leafs' [-Wenum-conversion]
                cpuid_entry_override(entry, CPUID_12_EAX);
                ~~~~~~~~~~~~~~~~~~~~        ^~~~~~~~~~~~
2 warnings generated.

Fixes: 4e66c0cb ("KVM: x86: Add support for reverse CPUID lookup of scattered features")
Cc: Kai Huang <kai.huang@intel.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Message-Id: <20210421010850.3009718-1-seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      90772c12
    • S
      KVM: x86: Add capability to grant VM access to privileged SGX attribute · 2c1e5e2f
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit fe7e9488
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit fe7e9488 KVM: x86: Add capability to grant VM
access to privileged SGX attribute.
Backport for SGX virtualization support

--------------------------------

Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by userspace
to grant a VM access to a priveleged attribute, with args[0] holding a
file handle to a valid SGX attribute file.

The SGX subsystem restricts access to a subset of enclave attributes to
provide additional security for an uncompromised kernel, e.g. to prevent
malware from using the PROVISIONKEY to ensure its nodes are running
inside a geniune SGX enclave and/or to obtain a stable fingerprint.

To prevent userspace from circumventing such restrictions by running an
enclave in a VM, KVM restricts guest access to privileged attributes by
default.

Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <0b099d65e933e068e3ea934b0523bab070cb8cea.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      2c1e5e2f
    • S
      KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC · 5698b7e8
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 72add915
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 72add915 KVM: VMX: Enable SGX virtualization for
SGX1, SGX2 and LC.
Backport for SGX virtualization support

--------------------------------

Enable SGX virtualization now that KVM has the VM-Exit handlers needed
to trap-and-execute ENCLS to ensure correctness and/or enforce the CPU
model exposed to the guest.  Add a KVM module param, "sgx", to allow an
admin to disable SGX virtualization independent of the kernel.

When supported in hardware and the kernel, advertise SGX1, SGX2 and SGX
LC to userspace via CPUID and wire up the ENCLS_EXITING bitmap based on
the guest's SGX capabilities, i.e. to allow ENCLS to be executed in an
SGX-enabled guest.  With the exception of the provision key, all SGX
attribute bits may be exposed to the guest.  Guest access to the
provision key, which is controlled via securityfs, will be added in a
future patch.

Note, KVM does not yet support exposing ENCLS_C leafs or ENCLV leafs.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <a99e9c23310c79f2f4175c1af4c4cbcef913c3e5.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      5698b7e8
    • S
      KVM: VMX: Add ENCLS[EINIT] handler to support SGX Launch Control (LC) · 97c47cac
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit b6f084ca
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit b6f084ca KVM: VMX: Add ENCLS[EINIT] handler to support
SGX Launch Control (LC).
Backport for SGX virtualization support

--------------------------------

Add a VM-Exit handler to trap-and-execute EINIT when SGX LC is enabled
in the host.  When SGX LC is enabled, the host kernel may rewrite the
hardware values at will, e.g. to launch enclaves with different signers,
thus KVM needs to intercept EINIT to ensure it is executed with the
correct LE hash (even if the guest sees a hardwired hash).

Switching the LE hash MSRs on VM-Enter/VM-Exit is not a viable option as
writing the MSRs is prohibitively expensive, e.g. on SKL hardware each
WRMSR is ~400 cycles.  And because EINIT takes tens of thousands of
cycles to execute, the ~1500 cycle overhead to trap-and-execute EINIT is
unlikely to be noticed by the guest, let alone impact its overall SGX
performance.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <57c92fa4d2083eb3be9e6355e3882fc90cffea87.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      97c47cac
    • S
      KVM: VMX: Add emulation of SGX Launch Control LE hash MSRs · 1766b14e
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 8f102445
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 8f102445 KVM: VMX: Add emulation of SGX Launch
Control LE hash MSRs.
Backport for SGX virtualization support

--------------------------------

Emulate the four Launch Enclave public key hash MSRs (LE hash MSRs) that
exist on CPUs that support SGX Launch Control (LC).  SGX LC modifies the
behavior of ENCLS[EINIT] to use the LE hash MSRs when verifying the key
used to sign an enclave.  On CPUs without LC support, the LE hash is
hardwired into the CPU to an Intel controlled key (the Intel key is also
the reset value of the LE hash MSRs). Track the guest's desired hash so
that a future patch can stuff the hash into the hardware MSRs when
executing EINIT on behalf of the guest, when those MSRs are writable in
host.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: NKai Huang <kai.huang@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <c58ef601ddf88f3a113add837969533099b1364a.1618196135.git.kai.huang@intel.com>
[Add a comment regarding the MSRs being available until SGX is locked.
 - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      1766b14e
    • S
      KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions · 6ad6cc5b
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 70210c04
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 70210c04 KVM: VMX: Add SGX ENCLS[ECREATE] handler
to enforce CPUID restrictions.
Backport for SGX virtualization support

--------------------------------

Add an ECREATE handler that will be used to intercept ECREATE for the
purpose of enforcing and enclave's MISCSELECT, ATTRIBUTES and XFRM, i.e.
to allow userspace to restrict SGX features via CPUID.  ECREATE will be
intercepted when any of the aforementioned masks diverges from hardware
in order to enforce the desired CPUID model, i.e. inject #GP if the
guest attempts to set a bit that hasn't been enumerated as allowed-1 in
CPUID.

Note, access to the PROVISIONKEY is not yet supported.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: NKai Huang <kai.huang@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <c3a97684f1b71b4f4626a1fc3879472a95651725.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      6ad6cc5b
    • S
      KVM: VMX: Frame in ENCLS handler for SGX virtualization · e4e22234
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 9798adbc
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 9798adbc KVM: VMX: Frame in ENCLS handler for
SGX virtualization.
Backport for SGX virtualization support

--------------------------------

Introduce sgx.c and sgx.h, along with the framework for handling ENCLS
VM-Exits.  Add a bool, enable_sgx, that will eventually be wired up to a
module param to control whether or not SGX virtualization is enabled at
runtime.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <1c782269608b2f5e1034be450f375a8432fb705d.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      e4e22234
    • S
      KVM: VMX: Add basic handling of VM-Exit from SGX enclave · 08f41fc4
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 3c0c2ad1
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 3c0c2ad1 KVM: VMX: Add basic handling of VM-Exit
from SGX enclave
Backport for SGX virtualization support

--------------------------------

Add support for handling VM-Exits that originate from a guest SGX
enclave.  In SGX, an "enclave" is a new CPL3-only execution environment,
wherein the CPU and memory state is protected by hardware to make the
state inaccesible to code running outside of the enclave.  When exiting
an enclave due to an asynchronous event (from the perspective of the
enclave), e.g. exceptions, interrupts, and VM-Exits, the enclave's state
is automatically saved and scrubbed (the CPU loads synthetic state), and
then reloaded when re-entering the enclave.  E.g. after an instruction
based VM-Exit from an enclave, vmcs.GUEST_RIP will not contain the RIP
of the enclave instruction that trigered VM-Exit, but will instead point
to a RIP in the enclave's untrusted runtime (the guest userspace code
that coordinates entry/exit to/from the enclave).

To help a VMM recognize and handle exits from enclaves, SGX adds bits to
existing VMCS fields, VM_EXIT_REASON.VMX_EXIT_REASON_FROM_ENCLAVE and
GUEST_INTERRUPTIBILITY_INFO.GUEST_INTR_STATE_ENCLAVE_INTR.  Define the
new architectural bits, and add a boolean to struct vcpu_vmx to cache
VMX_EXIT_REASON_FROM_ENCLAVE.  Clear the bit in exit_reason so that
checks against exit_reason do not need to account for SGX, e.g.
"if (exit_reason == EXIT_REASON_EXCEPTION_NMI)" continues to work.

KVM is a largely a passive observer of the new bits, e.g. KVM needs to
account for the bits when propagating information to a nested VMM, but
otherwise doesn't need to act differently for the majority of VM-Exits
from enclaves.

The one scenario that is directly impacted is emulation, which is for
all intents and purposes impossible[1] since KVM does not have access to
the RIP or instruction stream that triggered the VM-Exit.  The inability
to emulate is a non-issue for KVM, as most instructions that might
trigger VM-Exit unconditionally #UD in an enclave (before the VM-Exit
check.  For the few instruction that conditionally #UD, KVM either never
sets the exiting control, e.g. PAUSE_EXITING[2], or sets it if and only
if the feature is not exposed to the guest in order to inject a #UD,
e.g. RDRAND_EXITING.

But, because it is still possible for a guest to trigger emulation,
e.g. MMIO, inject a #UD if KVM ever attempts emulation after a VM-Exit
from an enclave.  This is architecturally accurate for instruction
VM-Exits, and for MMIO it's the least bad choice, e.g. it's preferable
to killing the VM.  In practice, only broken or particularly stupid
guests should ever encounter this behavior.

Add a WARN in skip_emulated_instruction to detect any attempt to
modify the guest's RIP during an SGX enclave VM-Exit as all such flows
should either be unreachable or must handle exits from enclaves before
getting to skip_emulated_instruction.

[1] Impossible for all practical purposes.  Not truly impossible
    since KVM could implement some form of para-virtualization scheme.

[2] PAUSE_LOOP_EXITING only affects CPL0 and enclaves exist only at
    CPL3, so we also don't need to worry about that interaction.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <315f54a8507d09c292463ef29104e1d4c62e9090.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      08f41fc4
    • S
      KVM: x86: Add reverse-CPUID lookup support for scattered SGX features · c66f4510
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 01de8682
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 01de8682 KVM: x86: Add reverse-CPUID lookup support
for scattered SGX features.
Backport for SGX virtualization support

--------------------------------

Define a new KVM-only feature word for advertising and querying SGX
sub-features in CPUID.0x12.0x0.EAX.  Because SGX1 and SGX2 are scattered
in the kernel's feature word, they need to be translated so that the
bit numbers match those of hardware.
Signed-off-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <e797c533f4c71ae89265bbb15a02aef86b67cbec.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      c66f4510
    • S
      KVM: x86: Add support for reverse CPUID lookup of scattered features · 09afd8d6
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 4e66c0cb
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 4e66c0cb KVM: x86: Add support for reverse CPUID
lookup of scattered features.
Backport for SGX virtualization support

--------------------------------

Introduce a scheme that allows KVM's CPUID magic to support features
that are scattered in the kernel's feature words.  To advertise and/or
query guest support for CPUID-based features, KVM requires the bit
number of an X86_FEATURE_* to match the bit number in its associated
CPUID entry.  For scattered features, this does not hold true.

Add a framework to allow defining KVM-only words, stored in
kvm_cpu_caps after the shared kernel caps, that can be used to gather
the scattered feature bits by translating X86_FEATURE_* flags into their
KVM-defined feature.

Note, because reverse_cpuid_check() effectively forces kvm_cpu_caps
lookups to be resolved at compile time, there is no runtime cost for
translating from kernel-defined to kvm-defined features.

More details here:  https://lkml.kernel.org/r/X/jxCOLG+HUO4QlZ@google.comSigned-off-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <16cad8d00475f67867fb36701fc7fb7c1ec86ce1.1618196135.git.kai.huang@intel.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      09afd8d6
    • S
      KVM: x86: Export kvm_mmu_gva_to_gpa_{read,write}() for SGX (VMX) · d0cb049e
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 54f958cd
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 54f958cd KVM: x86: Export
kvm_mmu_gva_to_gpa_{read,write}() for SGX (VMX).
Backport for SGX virtualization support

--------------------------------

Export the gva_to_gpa() helpers for use by SGX virtualization when
executing ENCLS[ECREATE] and ENCLS[EINIT] on behalf of the guest.
To execute ECREATE and EINIT, KVM must obtain the GPA of the target
Secure Enclave Control Structure (SECS) in order to get its
corresponding HVA.

Because the SECS must reside in the Enclave Page Cache (EPC), copying
the SECS's data to a host-controlled buffer via existing exported
helpers is not a viable option as the EPC is not readable or writable
by the kernel.

SGX virtualization will also use gva_to_gpa() to obtain HVAs for
non-EPC pages in order to pass user pointers directly to ECREATE and
EINIT, which avoids having to copy pages worth of data into the kernel.
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Acked-by: NJarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Message-Id: <02f37708321bcdfaa2f9d41c8478affa6e84b04d.1618196135.git.kai.huang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      d0cb049e
    • S
      x86/sgx: Introduce virtual EPC for use by KVM guests · 4fca036f
      由 Sean Christopherson 提交于 
      mainline inclusion
from mainline-5.13
commit 540745dd
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5EZEK
CVE: NA

Intel-SIG: commit 540745dd x86/sgx: Introduce virtual EPC for use by
KVM guests.
Backport for SGX virtualization support

--------------------------------

Add a misc device /dev/sgx_vepc to allow userspace to allocate "raw"
Enclave Page Cache (EPC) without an associated enclave. The intended
and only known use case for raw EPC allocation is to expose EPC to a
KVM guest, hence the 'vepc' moniker, virt.{c,h} files and X86_SGX_KVM
Kconfig.

The SGX driver uses the misc device /dev/sgx_enclave to support
userspace in creating an enclave. Each file descriptor returned from
opening /dev/sgx_enclave represents an enclave. Unlike the SGX driver,
KVM doesn't control how the guest uses the EPC, therefore EPC allocated
to a KVM guest is not associated with an enclave, and /dev/sgx_enclave
is not suitable for allocating EPC for a KVM guest.

Having separate device nodes for the SGX driver and KVM virtual EPC also
allows separate permission control for running host SGX enclaves and KVM
SGX guests.

To use /dev/sgx_vepc to allocate a virtual EPC instance with particular
size, the hypervisor opens /dev/sgx_vepc, and uses mmap() with the
intended size to get an address range of virtual EPC. Then it may use
the address range to create one KVM memory slot as virtual EPC for
a guest.

Implement the "raw" EPC allocation in the x86 core-SGX subsystem via
/dev/sgx_vepc rather than in KVM. Doing so has two major advantages:

  - Does not require changes to KVM's uAPI, e.g. EPC gets handled as
    just another memory backend for guests.

  - EPC management is wholly contained in the SGX subsystem, e.g. SGX
    does not have to export any symbols, changes to reclaim flows don't
    need to be routed through KVM, SGX's dirty laundry doesn't have to
    get aired out for the world to see, and so on and so forth.

The virtual EPC pages allocated to guests are currently not reclaimable.
Reclaiming an EPC page used by enclave requires a special reclaim
mechanism separate from normal page reclaim, and that mechanism is not
supported for virutal EPC pages. Due to the complications of handling
reclaim conflicts between guest and host, reclaiming virtual EPC pages
is significantly more complex than basic support for SGX virtualization.

 [ bp:
   - Massage commit message and comments
   - use cpu_feature_enabled()
   - vertically align struct members init
   - massage Virtual EPC clarification text
   - move Kconfig prompt to Virtualization ]
Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: NKai Huang <kai.huang@intel.com>
Signed-off-by: NKai Huang <kai.huang@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NDave Hansen <dave.hansen@intel.com>
Acked-by: NJarkko Sakkinen <jarkko@kernel.org>
Link: https://lkml.kernel.org/r/0c38ced8c8e5a69872db4d6a1c0dabd01e07cad7.1616136308.git.kai.huang@intel.comSigned-off-by: NFan Du <fan.du@intel.com>
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      4fca036f
  15. 06 7月, 2022 4 次提交