Skimming through the design docs, I saw some typos that needed fixing.
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Avoidance of deadlock is essential and since state must frequently be updated
that pertains to more than one domain, a locking protocol defines which locks
-are needed and the order of their acquistion.
+are needed and the order of their acquisition.
## Structure
## Hierarchical Locking Model and Protocol
-The locking discipline within the Argo code is heirarchical and utilizes
+The locking discipline within the Argo code is hierarchical and utilizes
reader/writer locks to enable increased concurrency when operations do not
conflict. None of the Argo locks are reentrant.
## Reasoning Model
-A common model for reasoning about concurrent code focusses on accesses to
+A common model for reasoning about concurrent code focuses on accesses to
individual variables: if code touches this variable, see that it first acquires
the corresponding lock and then drops it afterwards. A challenge with this
model is in ensuring that the sequence of locks acquired within nested
from the L1 hypervisor's perspective to be as close as possible to
the original hardware. In particular, the behavior of the hardware
on error paths 1) is not easy to understand or test, 2) can be the
- source of surprising vulnerabiliies. (See XSA-7 for an example of a
+ source of surprising vulnerabilities. (See XSA-7 for an example of a
case where subtle error-handling differences can open up a privilege
escalation.) We should avoid emulating any bit of the hardware with
complex error paths if we can at all help it.
- 2 `SVML` *SVM Lock*: Not required for L0, not provided to L1
- Seems to be aboult enabling an operating system to prevent "blue
+ Seems to be about enabling an operating system to prevent "blue
pill" attacks against itself.
Xen doesn't use it, nor provide it; so it would need to be
- implementend. The best way to protect a guest OS is to leave nested
+ implemented. The best way to protect a guest OS is to leave nested
virt disabled in the tools.
- 3 `NRIPS` NRIP Save: Require for both L0 and L1
The main putative use for this would be trying to maintain an
invariant TSC across cores with different clock speeds, or after a
migrate. Unlike others, this doesn't have an error path to worry
- about compatibility-wise; and according to tests done when nestedSVM
- was first implemented, it's actually faster to emliate TscRateMSR in
+ about compatibility-wise; and according to tests done when nested SVM
+ was first implemented, it's actually faster to emulate TscRateMSR in
the L0 hypervisor than for L1 to attempt to emulate it itself.
However, using this properly in L0 will take some implementation
- 5 `VmcbClean`: VMCB Clean Bits: Not required by L0, provide to L1
This is a pure optimization, both on the side of the L0 and L1. The
- implementaiton for L1 is entirely Xen-side, so can be provided even
+ implementation for L1 is entirely Xen-side, so can be provided even
on hardware that doesn't provide it. And it's purely an
optimization, so could be "implemented" by ignoring the bits
entirely.
- 6 `FlushByAsid`: Require for L0, provide to L1
This is cheap and easy to use for L0 and to provide to the L1;
- there's no reson not to just pass it through.
+ there's no reason not to just pass it through.
- 7 `DecodeAssists`: Require for L0, provide to L1
'''Description''': As mentioned above, having QEMU switch to a
non-root user, one per domain id. Not being the root user limits what
a compromised QEMU process can do to the system, and having one user
-per domain id limits what a comprimised QEMU process can do to the
+per domain id limits what a compromised QEMU process can do to the
QEMU processes of other VMs.
'''Implementation''': The toolstack adds the following to the qemu command-line:
## Namespaces for unused functionality (Linux only)
'''Description''': QEMU doesn't use the functionality associated with
-mount and IPC namespaces. (IPC namespaces contol non-file-based IPC
-mechanisms within the kernel; unix and network sockets are not
+mount and IPC namespaces. (IPC namespaces control non-file-based IPC
+mechanisms within the kernel; Unix and network sockets are not
affected by this.) Making separate namespaces for these for QEMU
won't affect normal operation, but it does mean that even if other
restrictions fail, the process won't be able to even name system mount
kill(-1, 9);
}
-Fortunately there is an assymetry we can take advantage of. From the
+Fortunately there is an asymmetry we can take advantage of. From the
POSIX spec:
> For a process to have permission to send a signal to a process
threads for some devices, so this would require some thought.
Other things that would take some cleverness / changes to QEMU to
-utilize due to ordering constrants:
+utilize due to ordering constraints:
- RLIMIT_NOFILES (after all necessary files are opened)
## libxl: Treat QMP connection as untrusted
the QMP socket, VNC socket, and so on).
It should be noted that `-sandbox` is implemented as a blacklist, not
-a whitelist; that is, it disables known-unsed functionality which may
+a whitelist; that is, it disables known-unused functionality which may
be harmful, rather than disabling all functionality except that known
to be safe and needed. This is unfortunately necessary since qemu
doesn't know what system calls libraries might end up making. (See
record previously present).
Each _committed_ node in the stream is required to have an already known parent
-node. A parent node is known if it was either in the node data base before the
+node. A parent node is known if it was either in the node database before the
stream was started to be processed, or if a `NODE_DATA` record for that parent
node has already been processed in the stream.
1. Mechanisms to restrict QEMU to only being able to affect its own
domain
- 2. Mechanisms to restruct QEMU's ability to interact with domain 0.
+ 2. Mechanisms to restrict QEMU's ability to interact with domain 0.
# User details
projects / people / royger / xen.git / commitdiff