In a typical implementation, the number of RCID bits implemented (for example, to
support 10s of RCIDs) might be smaller than the number of MCID bits
implemented (for example, to support 100s of MCIDs).
It is a typical usage to associate a group of applications/VMs with a common
RCID and thus sharing a common pool of resource allocations. The resource
allocations for the RCID is established to meet the SLA objectives of all
members of the group. If SLA objectives of one or more members of the group
stop being met, the resource usage of one or more members of the group might be
monitored by associating them with a unique MCID and this iterative analysis
process used to determine the optimal strategy - increasing resources allocated
to the RCID, moving some members to a different RCID, migrating some members
away to another machine, and so on. - for restoring the SLA. Having a sufficiently
large pool of MCID speeds up this analysis.
|
Note
|
To support maximal flexibility in allocation of QoS IDs to workloads, it is
recommended for all resource controllers in the system to support an identical
number of |
Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). These secure and isolated environments prevent unauthorized access or modification of applications and data while in use, thereby increasing the security assurances for organizations that manage sensitive and regulated data.
The resource accesses from a TEE must not be observable using the resource usage monitoring capability and the resource allocations for the TEE must be established by a TEE security monitor that manages the TEE.
The resource controllers in such SoC support configuration of separate resource allocations and resource usage monitoring for requests from originating from TEEs.
To differential requests to shared resources originating from TEEs from non-TEEs a confidential-access indicator accompanies requests made to the shared resources.
The resource controller might then use the confidential-access indicator along with the QoS identifiers that accompany the request to determine the resource allocations and the monitoring counters to use.
Supporting confidential computing thus requires following additional capabilities:
-
A secure register programming interface
-
A confidential-access indicator (
C)
To support secure execution, a CBQRI capable controller might provide a second register programming interface that is used to establish resource allocations and resource usage monitoring for secure execution. The secure register programming interface includes the same register layout and behavior defined as specified in this specification.
Access to the secure register programming interfaces should be restricted to the secure execution supervisor (for example, secure M-mode) by using the PMP.
The resource controllers that support confidential computing thus support two
set of resource allocation configurations - confidential and non-confidential -
for each RCID and AT. The confidential resource allocation configurations
can be accessed only through the secure register programming interface.
The resource controllers that support confidential computing thus support two
set of resource usage monitoring events and counters - confidential and
non-confidential - for each MCID and AT. The confidential monitoring events
and counters can be accessed only through the secure register programming
interface.
An implementation can restrict number of RCID and MCID that might be used for
confidential computing and thereby implement a smaller number of entries in the
configuration tables that can be programmed through the secure register
programming interface.
|
Note
|
To support maximal flexibility in allocation of QoS IDs to TEEs, it is
recommended for all resource controllers in the system to support an identical
number of |
Requests to access resources governed by QoS aware resource controllers is
associated by a confidential-access indicator (C) along with RCID, MCID,
and AT.
The C bit associated with the request indicates whether the access is to a
confidential resources (C=1) or to a non-confidential resource. For memory
controllers and caches, for example, the C bit can be determined as a property
of the memory region accessed.
Execution in a TEE generates requests associated with both settings of C
bit. For example, when a TEE accesses its confidential memory the C bit
associated with such requests will be 1 and when the TEE accesses
non-confidential memory (for example, memory buffers used by the TEE for communication
with agents outside the TEE), then the C bit associated the request will be 0.
Execution outside of a TEE might only be requests with C=0, as access to
confidential resources is restricted to TEEs.
For requests with C=1, resource controllers use the confidential resource
allocation configurations that were established by using the secure register
programming interface for the associated RCID and AT. For requests with
C=0, resource controllers use the configurations that were established by using
the non-secure register programming interface.
For requests with C=1, the monitoring events programmed through the secure
register programming events for the associated MCID and AT are triggered and
are counted in monitoring counters that can be accessed only by using the secure
register programming interface.
|
Note
|
The confidential-access indicator can be determined at the originator of the request and thus be carried along with the request or can be determined at the resource controller itself based on the properties of the address space accessed. |
Typically, the contents of the sqoscfg CSR is updated with a new RCID
and/or MCID by the HS/S-mode scheduler if the RCID and/or MCID of the
new process/VM is not same as that of the previous process/VM.
Usually, for virtual machines, the resource allocations are configured by the
hypervisor. Usually, the Guest OS in a virtual machine does not participate in
the QoS flows as the Guest OS does not know the physical capabilities of the
platform or the resource allocations for other virtual machines in the system.
If a use case requires it, a hypervisor can virtualize the QoS capability to a
VM by virtualizing the memory-mapped CBQRI register interface and by using the
virtual-instruction exception on access to sqoscfg CSR.
|
Note
|
If the use of directly selecting among a set of |
A Hypervisor might cause a context switch from one virtual machine to another. The
context switch usually involves saving the context associated with the VM that is being
switched away from and restoring the context of the VM that is being switched to. Such
context switch might be invoked in response to an explicit call from the VM (for example,
as a function of an ECALL invocation) or might be done asynchronously (for example, in
response to a timer interrupt). In such cases, the hypervisor might want to execute
with the sqoscfg configurations of the VM that is being switched away from so that
the execution is attributed to that VM. Then, before executing the context switch code
associated with restoring the new VMs context, first switch to the sqoscfg that is
appropriate for the new VM that is being switched to so that all of that execution
is attributed to the new VM. Further in this context switch process, if the hypervisor
intends some of the execution to be attributed to neither the outgoing VM nor the
incoming VM, then the hypervisor can switch to a new configuration that is different from
the configuration of either of the VMs for the duration of such execution. QoS
capabilities are statistical in nature and the small duration, such as the few
instructions in the hypervisor trap handler entrypoint for which the HS-mode can
execute with the RCID/MCID values established for lower privilege mode operation,
might not be statistically significant.
The RCID and MCID values configured in sqoscfg also apply to execution in
S/HS-mode, but is typically not an issue. Usually, S/HS-mode execution occurs to
provide services, such as through the SBI, to software executing at lower
privilege. Because the S/HS-mode invocation was to provide a service for the
lower privilege mode, the S/HS-mode software might not modify the sqoscfg CSR.
If a use case requires use of separate RCID and/or MCID for software
execution in S/HS-mode, then the S/HS-mode SW might update the sqoscfg CSR and
restore it before returning to the lower privilege mode execution.
The RCID and MCID configured in sqoscfg also apply to execution in M-mode
but is typically not an issue. Usually, M-mode execution occurs to provide
services, such as through the SBI interface, to software executing at lower
privilege. Because the M-mode invocation provides a service for the lower
privilege mode, the M-mode software might not modify the sqoscfg CSR. If a use
case requires the use of a separate RCID and/or MCID for software execution in
M-mode, then the M-mode SW can update the sqoscfg CSR and restore it before
returning to lower privilege mode execution.
Security monitors such as the TEE security monitor must protect the secure register programming interface from read or write access by non-secure entities. Methods such as PMPs, page tables, and so on can be employed to implementation such protection mechanisms.
When multiple security domains exists the control of the secure register programming interface must be retained by the security monitor that is in the trust boundary of the security domains controlled by that monitor.
When multiple security domains exists, the security manager of the security domains must not in general provide QoS information about one security domain to another or allow one security domain to affect the QoS configurations of another security domain; unless an explicit security policy defined by the security domain manager allows such sharing.