Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 8月, 2023 1 次提交
  3. 31 7月, 2023 2 次提交
  5. 20 7月, 2023 1 次提交
  7. 25 6月, 2023 1 次提交
  9. 18 5月, 2023 1 次提交
  11. 16 5月, 2023 1 次提交
  13. 25 4月, 2023 3 次提交
  15. 20 4月, 2023 2 次提交
    • K
      KVM/VMX: Allow exposing EDECCSSA user leaf function to KVM guest · 1b0e6dcb
      由 Kai Huang 提交于 
      mainline inclusion
from mainline-v6.2-rc1
commit 16a7fe37
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6X1FF
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16a7fe3728a8b832ef0d1add66875a666b1f24fc

Intel-SIG: commit 16a7fe37 KVM/VMX: Allow exposing EDECCSSA user
leaf function to KVM guest
Incremental backporting patches for SGX on Intel Xeon platform.

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

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: NKai Huang <kai.huang@intel.com>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Acked-by: NSean Christopherson <seanjc@google.com>
Acked-by: NJarkko Sakkinen <jarkko@kernel.org>
Link: https://lore.kernel.org/all/20221101022422.858944-1-kai.huang%40intel.com
[ Zhiquan: amend commit log and resolve the conflict.
  commit 01338078 ("KVM: x86: Move reverse CPUID helpers to separate
  header file") moved part of content from arch/x86/kvm/cpuid.h to
  arch/x86/kvm/reverse_cpuid.h.  The modifications have been applied on
  arch/x86/kvm/reverse_cpuid.h should be moved to arch/x86/kvm/cpuid.h.
]
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      1b0e6dcb
    • D
      x86/sgx: Allow enclaves to use Asynchrounous Exit Notification · ef8e3589
      由 Dave Hansen 提交于 
      mainline inclusion
from mainline-v6.2-rc1
commit 370839c2
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6X1FF
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=370839c241f7b98c66063c2892795a37ee3d2771

Intel-SIG: commit 370839c2 x86/sgx: Allow enclaves to use
Asynchrounous Exit Notification
Incremental backporting patches for SGX on Intel Xeon platform.

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

Short Version:

Allow enclaves to use the new Asynchronous EXit (AEX)
notification mechanism.  This mechanism lets enclaves run a
handler after an AEX event.  These handlers can run mitigations
for things like SGX-Step[1].

AEX Notify will be made available both on upcoming processors and
on some older processors through microcode updates.

Long Version:

== SGX Attribute Background ==

The SGX architecture includes a list of SGX "attributes".  These
attributes ensure consistency and transparency around specific
enclave features.

As a simple example, the "DEBUG" attribute allows an enclave to
be debugged, but also destroys virtually all of SGX security.
Using attributes, enclaves can know that they are being debugged.
Attributes also affect enclave attestation so an enclave can, for
instance, be denied access to secrets while it is being debugged.

The kernel keeps a list of known attributes and will only
initialize enclaves that use a known set of attributes.  This
kernel policy eliminates the chance that a new SGX attribute
could cause undesired effects.

For example, imagine a new attribute was added called
"PROVISIONKEY2" that provided similar functionality to
"PROVISIIONKEY".  A kernel policy that allowed indiscriminate use
of unknown attributes and thus PROVISIONKEY2 would undermine the
existing kernel policy which limits use of PROVISIONKEY enclaves.

== AEX Notify Background ==

"Intel Architecture Instruction Set Extensions and Future
Features - Version 45" is out[2].  There is a new chapter:

	Asynchronous Enclave Exit Notify and the EDECCSSA User Leaf Function.

Enclaves exit can be either synchronous and consensual (EEXIT for
instance) or asynchronous (on an interrupt or fault).  The
asynchronous ones can evidently be exploited to single step
enclaves[1], on top of which other naughty things can be built.

AEX Notify will be made available both on upcoming processors and
on some older processors through microcode updates.

== The Problem ==

These attacks are currently entirely opaque to the enclave since
the hardware does the save/restore under the covers. The
Asynchronous Enclave Exit Notify (AEX Notify) mechanism provides
enclaves an ability to detect and mitigate potential exposure to
these kinds of attacks.

== The Solution ==

Define the new attribute value for AEX Notification.  Ensure the
attribute is cleared from the list reserved attributes.  Instead
of adding to the open-coded lists of individual attributes,
add named lists of privileged (disallowed by default) and
unprivileged (allowed by default) attributes.  Add the AEX notify
attribute as an unprivileged attribute, which will keep the kernel
from rejecting enclaves with it set.

1. https://github.com/jovanbulck/sgx-step
2. https://cdrdv2.intel.com/v1/dl/getContent/671368?explicitVersion=trueSigned-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Acked-by: NJarkko Sakkinen <jarkko@kernel.org>
Tested-by: NHaitao Huang <haitao.huang@intel.com>
Tested-by: NKai Huang <kai.huang@intel.com>
Link: https://lore.kernel.org/all/20220720191347.1343986-1-dave.hansen%40linux.intel.com
[ Zhiquan: amend commit log. ]
Signed-off-by: NZhiquan Li <zhiquan1.li@intel.com>
      ef8e3589
  17. 19 4月, 2023 2 次提交
  19. 15 4月, 2023 3 次提交
  21. 17 3月, 2023 8 次提交
  23. 11 3月, 2023 1 次提交
  25. 08 3月, 2023 1 次提交
  27. 28 2月, 2023 1 次提交
  29. 25 2月, 2023 2 次提交
  31. 01 2月, 2023 2 次提交
  33. 30 1月, 2023 1 次提交
  35. 11 1月, 2023 1 次提交
  37. 08 12月, 2022 1 次提交
  39. 07 12月, 2022 2 次提交
  41. 02 12月, 2022 1 次提交
  43. 30 11月, 2022 2 次提交