Project ACRN hypervisor
Go to file
Junjie Mao ea4eadf0a5 hv: hypercalls: refactor permission-checking and dispatching logic
The current permission-checking and dispatching mechanism of hypercalls is
not unified because:

  1. Some hypercalls require the exact vCPU initiating the call, while the
     others only need to know the VM.
  2. Different hypercalls have different permission requirements: the
     trusty-related ones are enabled by a guest flag, while the others
     require the initiating VM to be the Service OS.

Without a unified logic it could be hard to scale when more kinds of
hypercalls are added later.

The objectives of this patch are as follows.

  1. All hypercalls have the same prototype and are dispatched by a unified
     logic.
  2. Permissions are checked by a unified logic without consulting the
     hypercall ID.

To achieve the first objective, this patch modifies the type of the first
parameter of hcall_* functions (which are the callbacks implementing the
hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The
doxygen-style documentations are updated accordingly.

To achieve the second objective, this patch adds to `struct hc_dispatch` a
`permission_flags` field which specifies the guest flags that must ALL be
set for a VM to be able to invoke the hypercall. The default value (which
is 0UL) indicates that this hypercall is for SOS only. Currently only the
`permission_flag` of trusty-related hypercalls have the non-zero value
GUEST_FLAG_SECURE_WORLD_ENABLED.

With `permission_flag`, the permission checking logic of hypercalls is
unified as follows.

  1. General checks
     i. If the VM is neither SOS nor having any guest flag that allows
        certain hypercalls, it gets #UD upon executing the `vmcall`
        instruction.
    ii. If the VM is allowed to execute the `vmcall` instruction, but
        attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0).
  2. Hypercall-specific checks
     i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the
        initiating VM must be SOS and the specified target VM cannot be a
        pre-launched VM. Otherwise the hypercall returns -EINVAL without
        further actions.
    ii. If the hypercall requires certain guest flags, the initiating VM
        must have all the required flags. Otherwise the hypercall returns
        -EINVAL without further actions.
   iii. A hypercall with an unknown hypercall ID makes the hypercall
        returns -EINVAL without further actions.

The logic above is different from the current implementation in the
following aspects.

  1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts
     to execute `vmcall` in ring 1, 2 or 3.
  2. A pre-launched VM now gets #UD (rather than the return value -EPERM)
     when it attempts to execute a trusty hypercall in ring 0.
  3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it
     attempts to invoke a trusty hypercall.
  4. A post-launched VM with trusty support now gets the return value
     -EINVAL (rather than #UD) when it attempts to invoke a non-trusty
     hypercall or an invalid hypercall.

v1 -> v2:
 - Update documentation that describe hypercall behavior.
 - Fix Doxygen warnings

Tracked-On: #5924
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2021-05-12 13:43:41 +08:00
.github/ISSUE_TEMPLATE Update bug_report.md 2020-07-23 22:50:26 +08:00
devicemodel OVMF temporary release 2021-05-07 14:16:37 +08:00
doc hv: hypercalls: refactor permission-checking and dispatching logic 2021-05-12 13:43:41 +08:00
hypervisor hv: hypercalls: refactor permission-checking and dispatching logic 2021-05-12 13:43:41 +08:00
misc config_tools: enable features for default config on tgl-rvp and 2021-05-12 09:20:03 +08:00
.checkpatch.conf
.clang-format config-tools: introduce xslt transform and clang-format in genconf.sh 2021-05-07 14:39:08 +08:00
.gitignore doc: update doc generation tooling to only work within the $BUILDDIR 2019-10-14 17:26:48 -04:00
CODEOWNERS doc: update CODEOWNERS for tech docs 2021-02-01 16:48:08 +08:00
LICENSE doc: update LICENSE copyright years 2020-12-18 15:12:18 +08:00
Makefile Makefile: create top-level target for the ACRN life_mngr 2021-03-29 15:38:29 +08:00
paths.make use variables for installation directories. 2020-06-05 15:25:12 +08:00
README.rst doc: add ACRN lockup logo to README 2020-12-15 10:36:42 -08:00
VERSION version: 2.5-unstable 2021-04-08 15:09:09 +08:00

Project ACRN Embedded Hypervisor
################################


.. raw:: html

   <img src="doc/images/ACRN_Logo_PrimaryLockup_COLOR-300x300-1.png"
   height="175px" align="right">

The open source project ACRN defines a device hypervisor reference stack
and an architecture for running multiple software subsystems, managed
securely, on a consolidated system by means of a virtual machine
manager. It also defines a reference framework implementation for
virtual device emulation, called the "ACRN Device Model".

The ACRN Hypervisor is a Type 1 reference hypervisor stack, running
directly on the bare-metal hardware, and is suitable for a variety of
IoT and embedded device solutions. The ACRN hypervisor addresses the
gap that currently exists between datacenter hypervisors, and hard
partitioning hypervisors. The ACRN hypervisor architecture partitions
the system into different functional domains, with carefully selected
guest OS sharing optimizations for IoT and embedded devices.

.. start_include_here

Community Support
*****************

The Project ACRN Developer Community includes developers from member
organizations and the general community all joining in the development of
software within the project. Members contribute and discuss ideas,
submit bugs and bug fixes. They also help those in need
through the community's forums such as mailing lists and IRC channels. Anyone
can join the developer community and the community is always willing to help
its members and the User Community to get the most out of Project ACRN.

Welcome to the project ARCN community!

We're now holding weekly Technical Community Meetings and encourage you
to call in and learn more about the project. Meeting information is on
the `TCM Meeting page`_ in our `ACRN wiki <https://wiki.projectacrn.org/>`_.

.. _TCM Meeting page:
   https://github.com/projectacrn/acrn-hypervisor/wiki/ACRN-Committee-and-Working-Group-Meetings#technical-community-meetings

Resources
*********

Here's a quick summary of resources to find your way around the Project
ACRN support systems:

* **Project ACRN Website**: The https://projectacrn.org website is the
  central source of information about the project. On this site, you'll
  find background and current information about the project as well as
  relevant links to project material.  For a quick start, refer to the
  `Introduction`_ and `Getting Started Guide`_.

* **Source Code in GitHub**: Project ACRN source code is maintained on a
  public GitHub repository at https://github.com/projectacrn/acrn-hypervisor.
  You'll find information about getting access to the repository and how to
  contribute to the project in this `Contribution Guide`_ document.

* **Documentation**: Project technical documentation is developed
  along with the project's code, and can be found at
  https://projectacrn.github.io.  Additional documentation is maintained in
  the `Project ACRN GitHub wiki`_.

* **Issue Reporting and Tracking**: Requirements and Issue tracking is done in
  the Github issues system: https://github.com/projectacrn/acrn-hypervisor/issues.
  You can browse through the reported issues and submit issues of your own.

* **Reporting a Potential Security Vulnerability**: If you have discovered potential
  security vulnerability in ACRN, please send an e-mail to secure@intel.com. For issues
  related to Intel Products, please visit https://security-center.intel.com.

  It is important to include the following details:

  - The projects and versions affected
  - Detailed description of the vulnerability
  - Information on known exploits

  Vulnerability information is extremely sensitive. Please encrypt all security vulnerability
  reports using our `PGP key`_.

  A member of the Intel Product Security Team will review your e-mail and contact you to
  to collaborate on resolving the issue. For more information on how Intel works to resolve
  security issues, see: `vulnerability handling guidelines`_.

* **Mailing List**: The `Project ACRN Development mailing list`_ is perhaps the most convenient
  way to track developer discussions and to ask your own support questions to
  the project ACRN community.  There are also specific `ACRN mailing list
  subgroups`_ for builds, users, and Technical
  Steering Committee notes, for example.
  You can read through the message archives to follow
  past posts and discussions, a good thing to do to discover more about the
  project.


.. _Introduction: https://projectacrn.github.io/latest/introduction/
.. _Getting Started Guide: https://projectacrn.github.io/latest/getting-started/
.. _Contribution Guide: https://projectacrn.github.io/latest/contribute.html
.. _Project ACRN GitHub wiki: https://github.com/projectacrn/acrn-hypervisor/wiki
.. _PGP Key: https://www.intel.com/content/www/us/en/security-center/pgp-public-key.html
.. _vulnerability handling guidelines:
   https://www.intel.com/content/www/us/en/security-center/vulnerability-handling-guidelines.html
.. _Project ACRN Development mailing list: https://lists.projectacrn.org/g/acrn-dev
.. _ACRN mailing list subgroups: https://lists.projectacrn.org/g/main/subgroups