1. 26 7月, 2023 1 次提交
  2. 25 4月, 2023 1 次提交
  3. 20 4月, 2023 1 次提交
    • 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
  4. 08 3月, 2023 1 次提交
  5. 02 12月, 2022 1 次提交
  6. 18 11月, 2022 3 次提交
  7. 11 11月, 2022 5 次提交
  8. 10 11月, 2022 1 次提交
  9. 04 11月, 2022 1 次提交
  10. 21 9月, 2022 1 次提交
    • D
      x86/speculation: Add RSB VM Exit protections · 30b1e4cb
      Daniel Sneddon 提交于
      stable inclusion
      from stable-v5.10.136
      commit 509c2c9fe75ea7493eebbb6bb2f711f37530ae19
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5N1SO
      CVE: CVE-2022-26373
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=509c2c9fe75ea7493eebbb6bb2f711f37530ae19
      
      --------------------------------
      
      commit 2b129932 upstream.
      
      tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
      documented for RET instructions after VM exits. Mitigate it with a new
      one-entry RSB stuffing mechanism and a new LFENCE.
      
      == Background ==
      
      Indirect Branch Restricted Speculation (IBRS) was designed to help
      mitigate Branch Target Injection and Speculative Store Bypass, i.e.
      Spectre, attacks. IBRS prevents software run in less privileged modes
      from affecting branch prediction in more privileged modes. IBRS requires
      the MSR to be written on every privilege level change.
      
      To overcome some of the performance issues of IBRS, Enhanced IBRS was
      introduced.  eIBRS is an "always on" IBRS, in other words, just turn
      it on once instead of writing the MSR on every privilege level change.
      When eIBRS is enabled, more privileged modes should be protected from
      less privileged modes, including protecting VMMs from guests.
      
      == Problem ==
      
      Here's a simplification of how guests are run on Linux' KVM:
      
      void run_kvm_guest(void)
      {
      	// Prepare to run guest
      	VMRESUME();
      	// Clean up after guest runs
      }
      
      The execution flow for that would look something like this to the
      processor:
      
      1. Host-side: call run_kvm_guest()
      2. Host-side: VMRESUME
      3. Guest runs, does "CALL guest_function"
      4. VM exit, host runs again
      5. Host might make some "cleanup" function calls
      6. Host-side: RET from run_kvm_guest()
      
      Now, when back on the host, there are a couple of possible scenarios of
      post-guest activity the host needs to do before executing host code:
      
      * on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not
      touched and Linux has to do a 32-entry stuffing.
      
      * on eIBRS hardware, VM exit with IBRS enabled, or restoring the host
      IBRS=1 shortly after VM exit, has a documented side effect of flushing
      the RSB except in this PBRSB situation where the software needs to stuff
      the last RSB entry "by hand".
      
      IOW, with eIBRS supported, host RET instructions should no longer be
      influenced by guest behavior after the host retires a single CALL
      instruction.
      
      However, if the RET instructions are "unbalanced" with CALLs after a VM
      exit as is the RET in #6, it might speculatively use the address for the
      instruction after the CALL in #3 as an RSB prediction. This is a problem
      since the (untrusted) guest controls this address.
      
      Balanced CALL/RET instruction pairs such as in step #5 are not affected.
      
      == Solution ==
      
      The PBRSB issue affects a wide variety of Intel processors which
      support eIBRS. But not all of them need mitigation. Today,
      X86_FEATURE_RSB_VMEXIT triggers an RSB filling sequence that mitigates
      PBRSB. Systems setting RSB_VMEXIT need no further mitigation - i.e.,
      eIBRS systems which enable legacy IBRS explicitly.
      
      However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RSB_VMEXIT
      and most of them need a new mitigation.
      
      Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE
      which triggers a lighter-weight PBRSB mitigation versus RSB_VMEXIT.
      
      The lighter-weight mitigation performs a CALL instruction which is
      immediately followed by a speculative execution barrier (INT3). This
      steers speculative execution to the barrier -- just like a retpoline
      -- which ensures that speculation can never reach an unbalanced RET.
      Then, ensure this CALL is retired before continuing execution with an
      LFENCE.
      
      In other words, the window of exposure is opened at VM exit where RET
      behavior is troublesome. While the window is open, force RSB predictions
      sampling for RET targets to a dead end at the INT3. Close the window
      with the LFENCE.
      
      There is a subset of eIBRS systems which are not vulnerable to PBRSB.
      Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB.
      Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO.
      
        [ bp: Massage, incorporate review comments from Andy Cooper. ]
      Signed-off-by: NDaniel Sneddon <daniel.sneddon@linux.intel.com>
      Co-developed-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      conflict:
          arch/x86/include/asm/cpufeatures.h
      Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
      Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
      Reviewed-by: NLiao Chang <liaochang1@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      30b1e4cb
  11. 20 9月, 2022 9 次提交
  12. 29 7月, 2022 1 次提交
  13. 13 7月, 2022 2 次提交
    • K
      Intel: AVX VNNI: x86: Enumerate AVX Vector Neural Network instructions · de9dc9ca
      Kyung Min Park 提交于
      mainline inclusion
      from mainline-5.11
      commit b85a0425
      category: feature
      feature: SPR New instructions
      bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I596EH
      CVE: N/A
      
      Intel-SIG: commit b85a0425 x86: Enumerate AVX Vector Neural Network instructions
      Backport for SPR core AVX VNNI support.
      
      ----------------------------
      
      Add AVX version of the Vector Neural Network (VNNI) Instructions.
      A processor supports AVX VNNI instructions if CPUID.0x07.0x1:EAX[4] is
      present. The following instructions are available when this feature is
      present.
      1. VPDPBUS: Multiply and Add Unsigned and Signed Bytes
      2. VPDPBUSDS: Multiply and Add Unsigned and Signed Bytes with Saturation
      3. VPDPWSSD: Multiply and Add Signed Word Integers
      4. VPDPWSSDS: Multiply and Add Signed Integers with Saturation
      
      The only in-kernel usage of this is kvm passthrough. The CPU feature
      flag is shown as "avx_vnni" in /proc/cpuinfo.
      
      This instruction is currently documented in the latest "extensions"
      manual (ISE). It will appear in the "main" manual (SDM) in the future.
      Signed-off-by: NKyung Min Park <kyung.min.park@intel.com>
      Signed-off-by: NYang Zhong <yang.zhong@intel.com>
      Reviewed-by: NTony Luck <tony.luck@intel.com>
      Message-Id: <20210105004909.42000-2-yang.zhong@intel.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NLuming Yu <luming.yu@intel.com>
      de9dc9ca
    • K
      Intel: 5G ISA: x86: Enumerate AVX512 FP16 CPUID feature flag · 82b4f867
      Kyung Min Park 提交于
      mainline inclusion
      from mainline-5.11
      commit e1b35da5
      category: feature
      feature: SPR New instructions
      bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I596EH
      CVE: N/A
      
      Intel-SIG: commit e1b35da5 x86: Enumerate AVX512 FP16 CPUID feature flag
      Backport for SPR core 5G ISA support.
      
      -------------------------------------
      
      Enumerate AVX512 Half-precision floating point (FP16) CPUID feature
      flag. Compared with using FP32, using FP16 cut the number of bits
      required for storage in half, reducing the exponent from 8 bits to 5,
      and the mantissa from 23 bits to 10. Using FP16 also enables developers
      to train and run inference on deep learning models fast when all
      precision or magnitude (FP32) is not needed.
      
      A processor supports AVX512 FP16 if CPUID.(EAX=7,ECX=0):EDX[bit 23]
      is present. The AVX512 FP16 requires AVX512BW feature be implemented
      since the instructions for manipulating 32bit masks are associated with
      AVX512BW.
      
      The only in-kernel usage of this is kvm passthrough. The CPU feature
      flag is shown as "avx512_fp16" in /proc/cpuinfo.
      
      Signed-off-by: Kyung Min Park kyung.min.park@intel.com
      Acked-by: Dave Hansen dave.hansen@intel.com
      Reviewed-by: Tony Luck tony.luck@intel.com
      Message-Id: 20201208033441.28207-2-kyung.min.park@intel.com
      Acked-by: Borislav Petkov bp@suse.de
      Signed-off-by: Paolo Bonzini pbonzini@redhat.com
      Signed-off-by: Luming Yu luming.yu@intel.com
      82b4f867
  14. 08 7月, 2022 2 次提交
  15. 06 7月, 2022 1 次提交
  16. 27 4月, 2022 1 次提交
  17. 22 2月, 2022 2 次提交
  18. 18 9月, 2020 2 次提交
  19. 08 9月, 2020 1 次提交
  20. 30 8月, 2020 1 次提交
  21. 26 8月, 2020 1 次提交
  22. 27 7月, 2020 1 次提交