This patch denies Service VM the access permission to device resources
owned by hypervisor.
HV may own these devices: (1) debug uart pci device for debug version
(2) type 1 pci device if have pre-launched VMs.
Current implementation exposes the mmio/pio resource of HV owned devices
to SOS, should remove them from SOS.
Tracked-On: #5615
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
This patch denies Service VM the access permission to device
resources owned by pre-launched VMs.
Rationale:
* Pre-launched VMs in ACRN are independent of service VM,
and should be immune to attacks from service VM. However,
current implementation exposes the bar resource of passthru
devices to service VM for some reason. This makes it possible
for service VM to crash or attack pre-launched VMs.
* It is same for hypervisor owned devices.
NOTE:
* The MMIO spaces pre-allocated to VFs are still presented to
Service VM. The SR-IOV capable devices assigned to pre-launched
VMs doesn't have the SR-IOV capability. So the MMIO address spaces
pre-allocated by BIOS for VFs are not decoded by hardware and
couldn't be enabled by guest. SOS may live with seeing the address
space or not. We will revisit later.
Tracked-On: #5615
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
If pre-launched VM co-exist with SOS, it must has higher severity
than SOS.
Tracked-On: #5615
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
The logical processor scoped IWKey can be copied to or from a
platform-scope storage copy called IWKeyBackup. Copying IWKey to
IWKeyBackup is called ‘backing up IWKey’ and copying from IWKeyBackup to
IWKey is called ‘restoring IWKey’.
IWKeyBackup and the path between it and IWKey are protected against
software and simple hardware attacks. This means that IWKeyBackup can be
used to distribute an IWKey within the logical processors in a platform
in a protected manner.
Linux keylocker implementation uses this feature, so they are
introduced by this patch.
Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Different vCPU may have different IWKeys. Hypervisor need do the iwkey
context switch.
This patch introduce a load_iwkey() function to do that. Switches the
host iwkey when the switch_in vCPU satisfies:
1) keylocker feature enabled
2) Different from the current loaded one.
Two opportunities to do the load_iwkey():
1) Guest enables CR4.KL bit.
2) vCPU thread context switch.
load_iwkey() costs ~600 cycles when do the load IWKey action.
Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
In order for a VMM to capture the IWKey values of guests, processors
that support Key Locker also support a new "LOADIWKEY exiting"
VM-execution control in bit 0 of the tertiary processor-based
VM-execution controls.
This patch enables the tertiary VM-execution controls.
Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
KeyLocker is a new security feature available in new Intel CPUs that
protects data-encryption keys for the Advanced Encryption Standard (AES)
algorithm.
This patch emulates Keylocker CPUID leaf 19H to support Keylocker
feature for guest VM.
To make the hypervisor being able to manage the IWKey correctly, this
patch doesn't expose hardware random IWKey capability
(CPUID.0x19.ECX[1]) to guest VM.
Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Bit19 (CR4_KL) of CR4 is CPU KeyLocker feature enable bit. Hypervisor
traps the bit's writing to track the keylocker feature on/off of guest.
While the bit is set by guest,
- set cr4_kl_enabled to indicate the vcpu's keylocker feature enabled status
- load vcpu's IWKey in host (will add in later patch)
While the bit is clear by guest,
- clear cr4_kl_enabled
This patch trap and passthru the CR4_KL bit to guest for operation.
Tracked-On: #5695
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
update scenaro xml templates when creating or loading new scenarios
according to config app folder reorg.
set default values for new create VMs from scenario schema when creating
a new scenario setting, adding a new VM, loading new default scenarios
for a new board;
add MBA_DELAY in generic scenario xml.
Tracked-On: #5672
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Reviewed-by: Mao, Junjie <junjie.mao@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Current implementation, SOS may allocate the memory region belonging to
hypervisor/pre-launched VM to a post-launched VM. Because it only verifies
the start address rather than the entire memory region.
This patch verifies the validity of the entire memory region before
allocating to a post-launched VM so that the specified memory can only
be allocated to a post-launched VM if the entire memory region is mapped
in SOS’s EPT.
Tracked-On: #5555
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Reviewed-by: Yonghua Huang <yonghua.huang@intel.com>
Try validate the scenario xml against schema if the config.xsd exsists.
Fix the regular expression pattern of IVSHMEM_REGION string validation.
Tracked-On: #5672
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Validation of the scenario XML files against the defined schema reveals
three typos. This patch fixes these errors.
Tracked-On: #5644
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
With a schema for scenario XML files, we no longer need to duplicate the
description, configurability and writeablity attributes in each XML
file.
This patch applies the following transformation to all scenario XML files
in order to remove these attributes.
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="@desc" />
<xsl:template match="@configurable | @multiselect | @readonly" />
<!-- The identity template -->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
Tracked-On: #5644
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Fix compilation issue when using gcc 10.x due to the "__packed"
attribute in acpi.h. Explicitly changing that to __attribute__((packed))
fixes the compilation error.
Tracked-On: #5671
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Documentation for the scenario XML configuration options is pulled from the
schema definition files (xsd) maintained in the misc/config_tools/schema
folder. Update the doc build process to generate and incorporate the
option documentation.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This patch introduces a schema (in XSD 1.1) for the scenario XML of ACRN
hypervisor for validation and documentation.
An XML schema defines the expected layout and value ranges of an XML
document. It allows a concise way to define our expectation on the
information in a scenario XML, including:
* structure of elements
* number of occurrences of elements with the same tags
* element data types and default values
* element descriptions
* any further properties such as readonly and configurable
Multiple XSD-based validators are available in the open source
community. A Python-based apporach will be introduced in a later patch and
integrated into the build system to ensure the integrity of the scenario
XML before we process it further.
A reference of the configuration data will be generated from the
<xs:documentation> blocks. Format for <xs:documentation> blocks will
properly output multiple text lines so features such as lists can be
used. All multi-line content must be left-aligned unless indentation is
specifically required by rst syntax. The trailing </xs:documentation> tag
should be on the same line as the last text line. For example:
<xs:simpleType name="SchedulerType">
<xs:annotation>
<xs:documentation>Three scheduler options are supported:
- ``SCHED_NOOP``: The NOOP (No-Operation) scheduler means there is a
strict 1 to 1 mapping between vCPUs and pCPUs.
- ``SCHED_IORR``: The IORR (IO sensitive Round Robin) scheduler supports
multipule vCPUs running on on one pCPU, scheduled by
a IO sensitive round robin policy.
``SCHED_BVT``: The BVT (Borrowed Virtual time) scheduler is a virtual
time based
scheduling algorithm, it dispatchs the runnable thread with the
earliest effective virtual time. *TODO: BVT scheduler will be built on
top of a prioritized scheduling mechanism, i.e. higher priority threads
get scheduled first, and same priority tasks are scheduled per BVT.*
Read more about the available scheduling options in
:ref:`cpu_sharing`.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="SCHED_NOOP" />
<xs:enumeration value="SCHED_IORR" />
<xs:enumeration value="SCHED_BVT" />
</xs:restriction>
</xs:simpleType>
Tracked-On: #5672
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Currently, we hardcode the GPA base of Software SRAM
to an address that is derived from TGL platform,
as this GPA is identical with HPA for Pre-launch VM,
This hardcoded address may not work on other platforms
if the HPA bases of Software SRAM are different.
Now, Offline tool configures above GPA based on the
detection of Software SRAM on specific platform.
This patch removes the hardcoding GPA of Software SRAM,
and also renames MACRO 'SOFTWARE_SRAM_BASE_GPA' to
'PRE_RTVM_SW_SRAM_BASE_GPA' to avoid confusing, as it
is for Prelaunch VM only.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
add fusa_partition scenario with 1 pre-launched Zephyr and 1 pre-launched
RTVM for ehl-crb-b board.
v2: fix the issue for build failure for partition mode by error check of
bootargs.
Tracked-On: #5665
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
update config folders used in config app based on config tool folders
reorg; remove "Generate configuration files" button from config app
since the function is deprecated.
Tracked-On: #5644
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
There is a comment in the doc/Makefile that is beinhg spit out
when calling 'make clean'. This is harmless but can be confusing
to users so let's make it silent.
Tracked-On: #5669
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
- RTCM is initialized in hypervisor only
if RTCM binaries are detected.
- Remove address space of RTCM binary from
Software SRAM region.
- Refine parse_rtct() function, validity of
ACPI RTCT table shall be checked by caller.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Physical address to SW SRAM region maybe different
on different platforms, this hardcoded address may
result in address mismatch for SW SRAM operations.
This patch removes above hardcoded address and uses
the physical address parsed from native RTCT.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
'ptcm' and 'ptct' are legacy name according
to the latest TCC spec, hence rename below files
to avoid confusing:
ptcm.c -> rtcm.c
ptcm.h -> rtcm.h
ptct.h -> rtct.h
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
GPA base of SW SRAM can't be hardcoded as physical address
of SW SRAM(HPA), as this HPA may vary on different platform.
This patch reserves a dedicated memory slot[GPA: 2G - 8M, 2G)
as SW SRAM region.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
This patch prepares vRTCT for post-RTVM instead of
pass-thru native RTCT:
- Configurations are based on Service VM native RTCT.
- Remap vLAPIC IDs in vRTCT.
- Remap base address of SW SRAM memory regions
from HPA to GPA.
- HPA base of Software SRAM shall be parsed from PTCT
instead of hardcoding.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
This patch add function 'vm_get_config()' to get
configuration information for current VM from hypervisor.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Remove the code that deals with the libtelemetry API and infrastructure.
Libtelemetry is used in Clear Linux only and not available (out of the
box) on Ubuntu or Yocto (which we use in our reference stack).
Tracked-On: #5653
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
This patch fixes the following issues that break the build system:
1. The tag of the root nodes of board/scenario XML files are still acrn-config,
not config_tools. This patch reverts the XPATH that refers to these nodes.
2. HV_PREDEFINED_BOARD_DIR now also relies on BOARD which may not be
available at the time the variable is defined. As both board and
scenario XML files are placed under the same directory, this patch
refines the path calculation logic to get rid of mixing variables of
the different flavors.
Tracked-On: #5644
Fixes: 97c9b24030 ("acrn-config: Reorg config tool folder")
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Replace the original Clear Linux (`swupd`) command to add the GCC
compiler for Windows by the equivalent in Ubuntu (i.e. using Ubuntu
package manager 'apt')
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
This patch parsees physical RTCT entries and dump information about pseudo
RAM into the board XML files. A macro named PRE_RTVM_SW_SRAM_BASE_GPA is
added to the generated misc_cfg.h according to recent design changes.
This patch still writes the board XML file manually, following the
convention of the current framework. Using XML-based approach requires a
complete refinement of the current generation process as the root
`acrn-config` node has its own text among adjacent children.
Tracked-On: #5649
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch ports the ACPI parsing module from BITS (BIOS Implementation
Test Suite) in order to ease the access to ACPI tables during board XML
generation. This library allows accessing ACPI table fields as Python class
members, getting rid of hard coding or calculating offsets within tables.
Compared to the original library, this port makes the following changes.
* Extract only the scripts and functions that contribute to ACPI parsing.
* Separate the parser of each ACPI table into different files.
* Read raw ACPI tables from Linux sysfs.
* Adapt to Python 3.
Tracked-On: #5649
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Simplify multiboot API by removing the global variable efiloader_sig.
Replaced by constant at the use site.
Tracked-On: #5661
Signed-off-by: Yi Liang <yi.liang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Remove include/boot.h since it contains only assembly variables that
should only be accessed in arch/x86/init.c.
Tracked-On: #5661
Signed-off-by: Yi Liang <yi.liang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Split off definition of "struct efi_info" into a separate header
file lib/efi.h.
Tracked-On: #5661
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
This is done by adding the MAX_MMAP_ENTRIES macro in multiboot.h.
This macro has to be sync-ed with E820_MAX_ENTRIES manually though.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The init_multiboot_info() and sanitize_multiboot_ifno() APIs now
require parameters instead of implicitly relying on global boot
variables.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Calling sanitize_multiboot() from init.c instead of cpu.c.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
This way, we void exposing acrn_mbi as a global variable.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
