FPT_HCL_EXT.1.2 and the Assurance Activity are modified (bold text) as follows:
5.8.3 FPT_HCL_EXT.1 Hypercall Controls
FPT_HCL_EXT.1.1 The TSF shall provide a Hypercall interface for Guest VMs to use to invoke functionality provided by the VMM.
FPT_HCL_EXT.1.2 The TSF shall allow administrators to configure any VM’s Hypercall interface to disable access to individual functions, all functions, or groups of functions.
FPT_HCL_EXT.1.3 The TSF shall permit exceptions to the configuration of the following Hypercall interface functions: [assignment: list of functions that are not subject to the configuration controls in FPT_HCL_EXT.1.2].
FPT_HCL_EXT.1.4 The TSF shall validate the parameters passed to the hypercall interface prior to execution of the VMM functionality exposed by that interface.
The purpose of this requirement is to help ensure the integrity of the VMM by defining the attack surface exposed to Guest VMs through Hypercalls, testing the mechanisms for reducing that attack surface by disabling Hypercalls, and ensuring that Hypercall parameters are properly validated prior to use by the VMM.
A Hypercall interface allows a set of VMM functions to be invoked by software running within a VM. Hypercall interfaces are used by virtualization-aware VMs to communicate and exchange data with the VMM. For example, a VM could use a hypercall interface to get information about the real world, such as the time of day or the underlying hardware of the host system. A hypercall could also be used to transfer data between VMs through a copy-paste mechanism. Because hypercall interfaces expose the VMM to Guest VMs, these interfaces constitute attack surface. In order to minimize attack surface, these interfaces must be limited to the minimum needed to support VM functionality.
For the assignment in FPT_HCL_EXT.1.3, the ST author lists the interface functions that cannot be configured per FPT_HCL_EXT.1.2.
A vendor-provided test harness may reduce evaluation time.
There is no expectation that the evaluator will need to review source code in order to accomplish the Assurance Activity. The evaluator documentation review should ensure that there are documented Hypercall functions in the TSS, that each documented Hypercall function contains the specified information, and that there are not obvious or publicly known Hypercall functions missing.
The evaluator shall examine the TSS or operational guidance to ensure it documents all Hypercall functions at the level necessary for the evaluator to disable the functions and run tests 1 and 2, below. Documentation must include, for each function, how to call the function, function parameters and legal values, configuration settings for enabling/disabling the function, and conditions under which the function can be disabled. The TSS must also specify those functions that cannot be disabled. While there is no expectation that the evaluator will need to examine source code in order to accomplish this Assurance Activity, the evaluator must ensure that there are no obvious or publicly known Hypercall functions missing from the TSS.
The evaluator shall examine the operational guidance to ensure it contains instructions for how to configure interface functions per FPT_HCL_EXT.1.2.
The evaluator shall perform the following tests:
1. For each configurable function that meets FPT_HCL_EXT.1.2, the evaluator shall follow the operational guidance to enable the function. The evaluator shall then attempt to call each function from within the VM. If the call is allowed, then the test succeeds.
2. For each configurable function that meets FPT_HCL_EXT.1.2, the evaluator shall configure the TSF to disable the function. The evaluator shall then attempt to call the function from within the VM. If the call is blocked, then the test succeeds.
This change refines the Application Note to better express the focus of this requirement, clarifies FPT_HCL_EXT.1.2, and clarifies the Assurance Activity.