github/acrn-hypervisor
1
0
Fork 0
mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2025-06-20 04:33:55 +00:00
Code Issues Projects Releases Wiki Activity

doc: hld-security hypervisor enhancement section update

Browse Source 
Update some content for hypervisor enhancement section
 to keep it consistent with the design.

Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
This commit is contained in:
Yonghua Huang 2019-10-18 15:27:57 +08:00 committed by deb-intel
parent 2727263422
commit 15e8130fcb
1 changed files with 14 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/developer-guides/hld/hld-security.rst
View File

@ -530,8 +530,12 @@ hypercall invocation in the hypervisor design:
World\_switch Hypercall is used by the TIPC (Trusty IPC) driver to World\_switch Hypercall is used by the TIPC (Trusty IPC) driver to
switch guest VM context between secure world and non-secure world. switch guest VM context between secure world and non-secure world.
Further details will be discussed in the :ref:`secure_trusty` section. Further details will be discussed in the :ref:`secure_trusty` section.
#. For those hypercalls that may result in data inconsistent intra hypervisor
when they are executed concurrently, such as ``hcall_create_vm()``
``hcll_destroy_vm()`` etc. spinlock is used to ensure these hypercalls
are processed in hypervisor in a serializing way.
In addition to these two rules, there are other regular checks in the In addition to above rules, there are other regular checks in the
hypercall implementation to prevent hypercalls from being misused. For hypercall implementation to prevent hypercalls from being misused. For
example, all the parameters must be sanitized, unexpected hypervisor example, all the parameters must be sanitized, unexpected hypervisor
memory overwrite must be avoided, any hypervisor memory content/secrets memory overwrite must be avoided, any hypervisor memory content/secrets
@ -542,15 +546,12 @@ I/O Emulation Handler
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
I/O port monitoring is also widely used by the ACRN hypervisor to I/O port monitoring is also widely used by the ACRN hypervisor to
emulate legacy I/O access behaviors. If the hypervisor cannot handle the emulate legacy I/O access behaviors.
I/O vmexit appropriately, a malicious driver in the guest VM could
manipulate the I/O access to compromise the hypervisor and its guest
VM(s).
Typically, the I/O instructions could be IN, INS/INSB/INSW/INSD, OUT, Typically, the I/O instructions could be IN, INS/INSB/INSW/INSD, OUT,
OUTS/OUTSB/OUTSW/OUTSD with arbitrary port (although not all the I/O OUTS/OUTSB/OUTSW/OUTSD with arbitrary port (although not all the I/O
ports are monitored by hypervisor). As with other interface (e.g. ports are monitored by hypervisor). As with other interface (e.g.
hypercalls), the hypervisor must perform security checks for all the I/O hypercalls), the hypervisor performs security checks for all the I/O
access parameters to make sure the emulation behaviors are correct. access parameters to make sure the emulation behaviors are correct.
EPT Violation Handler EPT Violation Handler
@ -571,7 +572,7 @@ There are some other VMEXIT handlers in the hypervisor which might take
untrusted parameters and registers from guest VM, for example, MSR write untrusted parameters and registers from guest VM, for example, MSR write
VMEXIT, APIC VMEXIT. VMEXIT, APIC VMEXIT.
Again, care must be taken by hypervisor to avoid security issue when Sanity checks are performed by hypervisor to avoid security issue when
handling those special VMEXIT. handling those special VMEXIT.
Guest Instruction Emulation Guest Instruction Emulation
@ -618,18 +619,8 @@ scrubbed by either DM or hypervisor, then the new launched UOS could
access the previous UOS's secrets by scanning the memory regions access the previous UOS's secrets by scanning the memory regions
allocated for the new UOS. allocated for the new UOS.
In a secure hypervisor and DM design, there are two solutions to solve In ACRN, the memory content is scrubbed in Device Model after the guest
this issue; the first one is preferred because it results in a smaller VM is shutdown.
attack window:
#. The memory content must be scrubbed immediately after the UOS is
shutdown or crashed.
#. The memory content must be scrubbed immediately before allocating a
memory area to launch a new UOS.
For project ACRN, the memory scrubbing operations could be done by the
hypervisor, DM, or vBIOS (vSBL). This is function design decision, which
is not in the scope of this document.
UOS Reboot UOS Reboot
~~~~~~~~~~ ~~~~~~~~~~
@ -655,8 +646,8 @@ the section on :ref:`platform_root_of_trust`.
Normally, this warm reboot (crashdump) feature is a debug feature, and Normally, this warm reboot (crashdump) feature is a debug feature, and
must be disabled in a production release. User who wants to use this must be disabled in a production release. User who wants to use this
feature must possess the private signing key to re-sign the image (e.g. feature must possess the private signing key to re-sign the image after
the virtual SBL image) after enabling the configuration. enabling the configuration.
.. _uos_suspend_resume: .. _uos_suspend_resume:
@ -673,8 +664,8 @@ SOS, the memory content of secure world of UOS must not be visible to
SOS. This is designed for security with defense in depth. SOS. This is designed for security with defense in depth.
During the entire process of UOS sleep/suspend, the memory protection During the entire process of UOS sleep/suspend, the memory protection
for secure-world must be preserved too.The physical memory region of for secure-world is preserved too.The physical memory region of
secure world must be removed from EPT paging tables of any guest VM, secure world is removed from EPT paging tables of any guest VM,
even including the SOS VM. even including the SOS VM.
Third-party libraries Third-party libraries