- Exit main() if pm_by_vuart_init() fails
- Use SIGHUP to gracefully power off a VM if pm_monitor_loop()
encounters a failure
- Identify a closed socket as a failure in pm_monitor_loop()
Tracked-On: #5736
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
RDT_ENABLED and PSRAM_ENABLED should not by y simultaneously.
Tracked-On: #5649
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Reviewed-by: Mao, Junjie <junjie.mao@intel.com>
Remove the the vuart1(tty) and vuart1(pty) poweroff channel from default
non-windows uos launch script xmls.
Tracked-On: #5736
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Accessing to software SRAM region is not allowed when
software SRAM is pass-thru to prelaunch RTVM.
This patch removes software SRAM region from service VM
EPT if it is enabled for prelaunch RTVM.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- Define 'PRE_RTVM_SW_SRAM_ENABLED' only if both
prelaunch RTVM and Software SRAM are configured in
current scenario.
- Define 'PRE_RTVM_SW_SRAM_BASE_GPA' and
'PRE_RTVM_SW_SRAM_END_GPA' only if
'PRE_RTVM_SW_SRAM_ENABLED' is defined.
Tracked-On: #5649
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Per ACPI 6.x chapter 6.1, "A device object must contain either an _HID object
or an _ADR object, but should not contain both."
Remove this object otherwise iasl would complain
"Warning 3073 - Multiple types ^ (Device object requires either a _HID
or _ADR, but not both)"
when launch post-launched VM in devicemodel.
Tracked-On: #5719
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Per ACPI 6.x chapter 19.6.109, the Processor Operator is deprecated.
Replace it with Device Operator, otherwise the iasl would complain
"Warning 3168 -
Legacy Processor() keyword detected. Use Device() keyword instead."
when launch post-launched VM in devicemodel.
Tracked-On: #5719
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Provide EFI support for SOS could cause weird issues. For example, hypervisor
works based on E820 table whereras it's possible that the memory map from EFI
table is not aligned with E820 table. The SOS kernel kaslr will try to find the
random address for extracted kernel image in EFI table first. So it's possible
that none-RAM in E820 is picked for extracted kernel image. This will make
kernel boot fail.
This patch removes EFI support for SOS by not passing struct boot_efi_info to
SOS kernel zeropage, and reserve a memory to store RSDP table for SOS and pass
the RSDP address to SOS kernel zeropage for SOS to locate ACPI table.
The patch requires SOS kernel version be high than 4.20, otherwise the kernel
might fail to find the RSDP.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Current memory allocation algorithm is to find the available address from
the highest possible address below max_address. If the function returns 0,
means all memory is used up and we have to put the resource at address 0,
this is dangerous for a running hypervisor.
Also returns 0 would make code logic very complicated, since memcpy_s()
doesn't support address 0 copy.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
In previous code, the rsdp initialization is done in get_rsdp() api implicitly.
The function is called multiple times in following acpi table parsing functions
and the condition (rsdp == NULL) need to be added in each parsing function.
This is not needed since the panic would occur if rsdp is NULL when do acpi
initialization.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
In this way, all multiboot standard data structure could be found in
multiboot_std.h. The multiboot_priv.h stores all private definitions
and multiboot.h is the only public API header file.
Tracked-On: #5661
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The device descriptor describes general information about a device,
the bcdUSB field contains a BCD version number. The version 3.2 is
represented with value of 0x320H. Add the missed BCD version in the
bcdUSB case statement. And modify the return value of address device
command in case create device failed.
Tracked-On: #5712
Signed-off-by: Liu Long <long.liu@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Loosen the restriction of IVSHMEM_REGION of xsd validation. An ivshmem
region can be shared by more than two vms.
Tracked-On: #5672
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
change generic folder to generic_board folder in config app according
to the reorg data folders and update the method to save xmls.
Tracked-On: #5723
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
update entry point address for pre-launched zephyr on ehl-crb-b;
update serial console to /dev/ttyS3 on ehl-crb-b.
Tracked-On: #5689
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Currently the VM bootargs load address is hard-coded at 8KB right before
kernel load address, this should work for Linux guest kernel only. Linux
kernel bzImage boot protocol guarantees its load address to be high than
GPA 8K so the address would never be overflowed, other OS like Zephyr
has no such assumption.
Tracked-On: #5689
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
add validate_scenario_schema to validate_scenario_setting and update the
excption handling.
Tracked-On: #5672
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
resize vm_config buffer from 16KB to 32KB, as 16KB
is not enough on EHL platform, which will result in
crash when accessing this memory.
Tracked-On: #5649
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
add SW SRAM config for hybrid_rt and industry scenarios on tgl-rvp
and ehl-crb-b boards.
Tracked-On: #5649
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
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>
