Commit Graph

21 Commits

Author SHA1 Message Date
szhen11 c29e9e9d4c Revert "hv: change 'DISABLED' settings to 'ENABLED'"
This reverts commit 8c5bb8b471.
2022-08-18 16:20:41 +08:00
Wu Zhou 8c5bb8b471 hv: change 'DISABLED' settings to 'ENABLED'
In order to improve DX, 'DISABLED' style configurator settings are
changed to 'ENABLED' style. The meaning of the MACROs are reversed,
so in the hv code we have to change '#ifndef' -> '#ifdef' or
'#ifdef' -> '#ifndef'.

Including:
  - MCE_ON_PSC_DISABLED -> MCE_ON_PSC_ENABLED
  - ENFORCE_TURNOFF_AC -> SPLIT_LOCK_DETECTION_ENABLED
  - ENFORCE_TURNOFF_GP -> UC_LOCK_DETECTION_ENABLED

Tracked-On: #7661
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
2022-08-17 09:23:33 +08:00
Yifan Liu 4f4da08490 hv: cve hotfix: Disable RRSBA on platform using retpoline
For platform that supports RRSBA (Restricted Return Stack Buffer
Alternate), using retpoline may not be sufficient to guard against branch
history injection or intra-mode branch target injection. RRSBA must
be disabled to prevent CPUs from using alternate predictors for RETs.

Quoting Intel CVE-2022-0001/CVE-2022-0002:

Where software is using retpoline as a mitigation for BHI or intra-mode BTI,
and the processor both enumerates RRSBA and enumerates RRSBA_DIS controls,
it should disable this behavior.
...
Software using retpoline as a mitigation for BHI or intra-mode BTI should use
these new indirect predictor controls to disable alternate predictors for RETs.

See: https://www.intel.com/content/www/us/en/developer/articles/technical/
 software-security-guidance/technical-documentation/branch-history-injection.html

Tracked-On: #7907
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
2022-07-22 09:38:41 +08:00
Ziheng Li eb8bcb06b3 Update copyright year range in code headers
Modified the copyright year range in code, and corrected "int32_tel"
into "Intel" in two "hypervisor/include/debug/profiling.h" and
"hypervisor/include/debug/profiling_internal.h".

Tracked-On: #7559
Signed-off-by: Ziheng Li <ziheng.li@intel.com>
2022-07-15 11:48:35 +08:00
Geoffroy Van Cutsem 8b16be9185 Remove "All rights reserved" string headers
Many of the license and Intel copyright headers include the "All rights
reserved" string. It is not relevant in the context of the BSD-3-Clause
license that the code is released under. This patch removes those strings
throughout the code (hypervisor, devicemodel and misc).

Tracked-On: #7254
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
2022-04-06 13:21:02 +08:00
Liang Yi 688a41c290 hv: mod: do not use explicit arch name when including headers
Instead of "#include <x86/foo.h>", use "#include <asm/foo.h>".

In other words, we are adopting the same practice in Linux kernel.

Tracked-On: #5920
Signed-off-by: Liang Yi <yi.liang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2021-05-08 11:15:46 +08:00
Liang Yi 33ef656462 hv/mod-irq: use arch specific header files
Requires explicit arch path name in the include directive.

The config scripts was also updated to reflect this change.

Tracked-On: #5825
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2021-03-24 11:38:14 +08:00
Shuo A Liu c11c07e0fe hv: keylocker: Support Key Locker feature for guest VM
KeyLocker is a new security feature available in new Intel CPUs that
protects data-encryption keys for the Advanced Encryption Standard (AES)
algorithm. These keys are more valuable than what they guard. If stolen
once, the key can be repeatedly used even on another system and even
after vulnerability closed.

It also introduces a CPU-internal wrapping key (IWKey), which is a key-
encryption key to wrap AES keys into handles. While the IWKey is
inaccessible to software, randomizing the value during the boot-time
helps its value unpredictable.

Keylocker usage:
 - New “ENCODEKEY” instructions take original key input and returns HANDLE
   crypted by an internal wrap key (IWKey, init by “LOADIWKEY” instruction)
 - Software can then delete the original key from memory
 - Early in boot/software, less likely to have vulnerability that allows
   stealing original key
 - Later encrypt/decrypt can use the HANDLE through new AES KeyLocker
   instructions
 - Note:
      * Software can use original key without knowing it (use HANDLE)
      * HANDLE cannot be used on other systems or after warm/cold reset
      * IWKey cannot be read from CPU after it's loaded (this is the
        nature of this feature) and only 1 copy of IWKey inside CPU.

The virtualization implementation of Key Locker on ACRN is:
 - Each vCPU has a 'struct iwkey' to store its IWKey in struct
   acrn_vcpu_arch.
 - At initilization, every vCPU is created with a random IWKey.
 - Hypervisor traps the execution of LOADIWKEY (by 'LOADIWKEY exiting'
   VM-exectuion control) of vCPU to capture and save the IWKey if guest
   set a new IWKey. Don't support randomization (emulate CPUID to
   disable) of the LOADIWKEY as hypervisor cannot capture and save the
   random IWKey. From keylocker spec:
   "Note that a VMM may wish to enumerate no support for HW random IWKeys
   to the guest (i.e. enumerate CPUID.19H:ECX[1] as 0) as such IWKeys
   cannot be easily context switched. A guest ENCODEKEY will return the
   type of IWKey used (IWKey.KeySource) and thus will notice if a VMM
   virtualized a HW random IWKey with a SW specified IWKey."
 - In context_switch_in() of each vCPU, hypervisor loads that vCPU's
   IWKey into pCPU by LOADIWKEY instruction.
 - There is an assumption that ACRN hypervisor will never use the
   KeyLocker feature itself.

This patch implements the vCPU's IWKey management and the next patch
implements host context save/restore IWKey logic.

Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-02-03 13:54:45 +08:00
liujunming 538e7cf74d hv:cpu-caps:refine processor family and model info
v3 -> v4:
Refine commit message and code stype

1.
SDM Vol. 2A 3-211 states DisplayFamily = Extended_Family_ID + Family_ID
when Family_ID == 0FH.
So it should be family += ((eax >> 20U) & 0xffU) when Family_ID == 0FH.

2.
IF (Family_ID = 06H or Family_ID = 0FH)
	THEN DisplayModel = (Extended_Model_ID « 4) + Model_ID;
While previous code this logic:
IF (DisplayFamily = 06H or DisplayFamily = 0FH)

Fix the bug about calculation of display family and
display model according to SDM definition.

3. use variable name to distinguish Family ID/Display Family/Model ID/Display Model,
then the code is more clear to avoid some mistake

Tracked-On:#3675

Signed-off-by: liujunming <junming.liu@intel.com>
Reviewed-by: Wu Xiangyang <xiangyang.wu@linux.intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-08-14 10:08:50 +08:00
Binbin Wu 0570993b40 hv: config: add an option to disable mce on psc workaround
Add a option MCE_ON_PSC_WORKAROUND_DISABLED to disable the software
workaround for the issue Machine Check Error on Page Size Change.

Tracked-On: #4101
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-12-03 09:17:04 +08:00
Binbin Wu 192859ee02 hv: ept: apply MCE on page size change mitigation conditionally
Only apply the software workaround on the models that might be
affected by MCE on page size change. For these models that are
known immune to the issue, the mitigation is turned off.

Atom processors are not afftected by the issue.
Also check the CPUID & MSR to check whether the model is immune to the issue:
CPU is not vulnerable when both CPUID.(EAX=07H,ECX=0H).EDX[29] and
IA32_ARCH_CAPABILITIES[IF_PSCHANGE_MC_NO] are 1.

Other cases not listed above, CPU may be vulnerable.

This patch also changes MACROs for MSR IA32_ARCH_CAPABILITIES bits to UL instead of U
since the MSR is 64bit.

Tracked-On: #4101
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-12-03 09:17:04 +08:00
Yonghua Huang 1ea3052f80 HV: check security mitigation support for SSBD
Hypervisor exposes mitigation technique for Speculative
Store Bypass(SSB) to guests and allows a guest to determine
whether to enable SSBD mitigation by providing direct guest
access to IA32_SPEC_CTRL.

Before that, hypervisor should check the SSB mitigation support
on underlying processor, this patch is to add this capability check.

Tracked-On: #3385
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-07-10 10:55:34 +08:00
Yonghua Huang 3164f3976a hv: Mitigation for CPU MDS vulnerabilities.
Microarchitectural Data Sampling (MDS) is a hardware vulnerability
 which allows unprivileged speculative access to data which is available
 in various CPU internal buffers.

 1. Mitigation on ACRN:
    1) Microcode update is required.
    2) Clear CPU internal buffers (store buffer, load buffer and
       load port) if current CPU is affected by MDS, when VM entry
       to avoid any information leakage to guest thru above buffers.
    3) Mitigation is not needed if ARCH_CAP_MDS_NO bit (bit5)
       is set in IA32_ARCH_CAPABILITIES MSR (10AH), in this case,
       current processor is no affected by MDS vulnerability, in other
       cases mitigation for MDS is required.

 2. Methods to clear CPU buffers (microcode update is required):
    1) L1D cache flush
    2) VERW instruction
    Either of above operations will trigger clearing all
    CPU internal buffers if this CPU is affected by MDS.
    Above mechnism is enumerated by:
    CPUID.(EAX=7H, ECX=0):EDX[MD_CLEAR=10].

 3. Mitigation details on ACRN:
    if (processor is affected by MDS)
	    if (processor is not affected by L1TF OR
		  L1D flush is not launched on VM Entry)
		    execute VERW instruction when VM entry.
	    endif
    endif

 4. Referrence:
    Deep Dive: Intel Analysis of Microarchitectural Data Sampling
    https://software.intel.com/security-software-guidance/insights/
    deep-dive-intel-analysis-microarchitectural-data-sampling

    Deep Dive: CPUID Enumeration and Architectural MSRs
    https://software.intel.com/security-software-guidance/insights/
    deep-dive-cpuid-enumeration-and-architectural-msrs

Tracked-On: #3317
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Anthony Xu <anthony.xu@intel.com>
Reviewed-by: Jason CJ Chen <jason.cj.chen@intel.com>
2019-07-05 15:17:27 +08:00
Yonghua Huang 076a30b555 hv: refine security capability detection function.
ACRN hypervisor always print CPU microcode update
 warning message on KBL NUC platform, even after
 BIOS was updated to the latest.

 'check_cpu_security_cap()' returns false if
 no ARCH_CAPABILITIES MSR support on current platform,
 but this MSR may not be available on some platforms.
 This patch is to remove this pre-condition.

Tracked-On: #3317
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Jason CJ Chen <jason.cj.chen@intel.com>
2019-07-05 15:17:27 +08:00
Minggui Cao fc1cbebe31 HV: remove vcpu arch lock, not needed.
the pcpu just write its own vmcs, not need spinlock.
and the arch.lock not used other places, remove it too.

Tracked-On: #3130

Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-05-22 16:35:26 +08:00
Kaige Fu a85d11ca7a HV: Add prefix 'p' before 'cpu' to physical cpu related functions
This patch adds prefix 'p' before 'cpu' to physical cpu related functions.
And there is no code logic change.

Tracked-On: #2991
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-04-24 10:50:28 +08:00
Huihuang Shi b316bf8a39 hv: fix "Else alternative missing in if."
All if . . else if constructs shall be
terminated with an else statement.

Tracked-On: #861
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com
2019-04-03 09:20:55 +08:00
Li, Fei1 738f2536fe hv: coding style: refine cpu related function to one exit
2) Fix procedure has more than one exit point.

Tracked-On: #861
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
2018-12-21 13:34:01 +08:00
Jason Chen CJ 97132acccf Make ibrs_type as internal variable
add get_ibrs_type API to get ibrs type.
this patch fix Misra C violation:
filename:/hypervisor/arch/x86/security.c  function:None  offset:19:
       reason:Variable should be declared static. : ibrs_type

Tracked-On: #861
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2018-12-19 09:07:14 +08:00
Jason Chen CJ 55cce7e4ca Fix Misra C violation in cpu_caps.c and security.c
Fixed below violations:
filename:/hypervisor/arch/x86/cpu_caps.c  function:None  offset:35:
       reason:Variable should be declared static. : cpu_caps
filename:/hypervisor/arch/x86/cpu_caps.c  function:is_vmx_disabled  offset:299:
       reason:Logical conjunctions need brackets.
filename:/hypervisor/arch/x86/cpu_caps.c  function:is_vmx_disabled  offset:300:
       reason:Logical conjunctions need brackets.
filename:/hypervisor/arch/x86/security.c  function:None  offset:18:
       reason:Scope of variable could be reduced. : x86_arch_capabilities
filename:/hypervisor/arch/x86/security.c  function:check_cpu_security_cap  offset:64:
       reason:Logical conjunctions need brackets.
filename:/hypervisor/arch/x86/security.c  function:check_cpu_security_cap  offset:65:
       reason:Logical conjunctions need brackets.

Tracked-On: #861
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2018-12-19 09:07:14 +08:00
Jason Chen CJ 5968da4635 move security related funcs into security.c
there are still some security related funcs in cpu_caps.c & cpu.c,
move them out into security.c.

Changes to be committed:
	modified:   Makefile
	modified:   arch/x86/cpu.c
	modified:   arch/x86/cpu_caps.c
	modified:   arch/x86/guest/vcpu.c
	new file:   arch/x86/security.c
	modified:   arch/x86/trusty.c
	modified:   arch/x86/vmx_asm.S
	modified:   include/arch/x86/cpu.h
	modified:   include/arch/x86/cpu_caps.h
	modified:   include/arch/x86/per_cpu.h
	new file:   include/arch/x86/security.h

Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2018-12-19 09:07:14 +08:00