mirror of
https://github.com/projectacrn/acrn-hypervisor.git
synced 2025-04-29 04:04:05 +00:00
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>
39 lines
803 B
C
39 lines
803 B
C
/*
|
|
* Copyright (C) 2018 Intel Corporation. All rights reserved.
|
|
*
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
*/
|
|
|
|
#ifndef SECURITY_H
|
|
#define SECURITY_H
|
|
|
|
/* type of speculation control
|
|
* 0 - no speculation control support
|
|
* 1 - raw IBRS + IBPB support
|
|
* 2 - with STIBP optimization support
|
|
*/
|
|
#define IBRS_NONE 0
|
|
#define IBRS_RAW 1
|
|
#define IBRS_OPT 2
|
|
|
|
#ifndef ASSEMBLER
|
|
int32_t get_ibrs_type(void);
|
|
void cpu_l1d_flush(void);
|
|
bool check_cpu_security_cap(void);
|
|
void cpu_internal_buffers_clear(void);
|
|
bool is_ept_force_4k_ipage(void);
|
|
uint64_t get_random_value(void);
|
|
|
|
#ifdef STACK_PROTECTOR
|
|
struct stack_canary {
|
|
/* Gcc generates extra code, using [fs:40] to access canary */
|
|
uint8_t reserved[40];
|
|
uint64_t canary;
|
|
};
|
|
void set_fs_base(void);
|
|
#endif
|
|
|
|
#endif /* ASSEMBLER */
|
|
|
|
#endif /* SECURITY_H */
|