| Message ID | 692dabc63953fb0d33536f87e4c5c147ba6ce11c.1736948633.git.bernhard.kaindl@cloud.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Design docs: Fix some typos in the design docs | expand |
On Wed, Jan 15, 2025 at 1:45 PM Bernhard Kaindl <bernhard.kaindl@cloud.com> wrote: > > Skimming through the design docs, I saw some typos that needed fixing. > > --- > Comments for reviewers (not for the commit message itself): > > Sample typos (some are not easy to spot): > - heirarchical: (ei->ie) > - implementaiton: (it->ti) > - comprimised: (i->o) > - contol->control (r) > > PS: I did the fixes using LTeX in an IDE and re-checked the mail too. > > Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com> > --- > docs/designs/argo.pandoc | 4 ++-- > docs/designs/nested-svm-cpu-features.md | 12 ++++++------ > docs/designs/qemu-deprivilege.md | 8 ++++---- > docs/designs/xenstore-migration.md | 2 +- > docs/features/qemu-deprivilege.pandoc | 2 +- > 5 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc > index e18aacea7c..cd854d2a7a 100644 > --- a/docs/designs/argo.pandoc > +++ b/docs/designs/argo.pandoc > @@ -58,7 +58,7 @@ concurrency. > > 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 > > @@ -127,7 +127,7 @@ by the domain. > > ## 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. > > diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md > index 837a96df05..c855748141 100644 > --- a/docs/designs/nested-svm-cpu-features.md > +++ b/docs/designs/nested-svm-cpu-features.md > @@ -22,7 +22,7 @@ leaf 8000000A:edx > 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. > @@ -59,11 +59,11 @@ leaf 8000000A:edx > > - 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 > @@ -78,8 +78,8 @@ leaf 8000000A:edx > 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 > @@ -89,7 +89,7 @@ leaf 8000000A:edx > - 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. > diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md > index f12b1a3ae3..603491f24d 100644 > --- a/docs/designs/qemu-deprivilege.md > +++ b/docs/designs/qemu-deprivilege.md > @@ -22,7 +22,7 @@ The following restrictions are currently implemented. > '''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: > @@ -79,8 +79,8 @@ Then 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 > @@ -251,7 +251,7 @@ executing QEMU. (But this would then require other changes to create > 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 > diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md > index 5022268386..082314bf72 100644 > --- a/docs/designs/xenstore-migration.md > +++ b/docs/designs/xenstore-migration.md > @@ -372,7 +372,7 @@ or modified by a transaction for which there is also a `TRANSACTION_DATA` > 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. > > diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc > index 4ef119c821..915e38d8c9 100644 > --- a/docs/features/qemu-deprivilege.pandoc > +++ b/docs/features/qemu-deprivilege.pandoc > @@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU running in domain > > 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 > Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com> Frediano
diff --git a/docs/designs/argo.pandoc b/docs/designs/argo.pandoc index e18aacea7c..cd854d2a7a 100644 --- a/docs/designs/argo.pandoc +++ b/docs/designs/argo.pandoc @@ -58,7 +58,7 @@ concurrency. 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 @@ -127,7 +127,7 @@ by the domain. ## 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. diff --git a/docs/designs/nested-svm-cpu-features.md b/docs/designs/nested-svm-cpu-features.md index 837a96df05..c855748141 100644 --- a/docs/designs/nested-svm-cpu-features.md +++ b/docs/designs/nested-svm-cpu-features.md @@ -22,7 +22,7 @@ leaf 8000000A:edx 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. @@ -59,11 +59,11 @@ leaf 8000000A:edx - 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 @@ -78,8 +78,8 @@ leaf 8000000A:edx 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 @@ -89,7 +89,7 @@ leaf 8000000A:edx - 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. diff --git a/docs/designs/qemu-deprivilege.md b/docs/designs/qemu-deprivilege.md index f12b1a3ae3..603491f24d 100644 --- a/docs/designs/qemu-deprivilege.md +++ b/docs/designs/qemu-deprivilege.md @@ -22,7 +22,7 @@ The following restrictions are currently implemented. '''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: @@ -79,8 +79,8 @@ Then 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 @@ -251,7 +251,7 @@ executing QEMU. (But this would then require other changes to create 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 diff --git a/docs/designs/xenstore-migration.md b/docs/designs/xenstore-migration.md index 5022268386..082314bf72 100644 --- a/docs/designs/xenstore-migration.md +++ b/docs/designs/xenstore-migration.md @@ -372,7 +372,7 @@ or modified by a transaction for which there is also a `TRANSACTION_DATA` 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. diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc index 4ef119c821..915e38d8c9 100644 --- a/docs/features/qemu-deprivilege.pandoc +++ b/docs/features/qemu-deprivilege.pandoc @@ -25,7 +25,7 @@ dm_restrict is a set of operations to restrict QEMU running in domain 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
Skimming through the design docs, I saw some typos that needed fixing. --- Comments for reviewers (not for the commit message itself): Sample typos (some are not easy to spot): - heirarchical: (ei->ie) - implementaiton: (it->ti) - comprimised: (i->o) - contol->control (r) PS: I did the fixes using LTeX in an IDE and re-checked the mail too. Signed-off-by: Bernhard Kaindl <bernhard.kaindl@cloud.com> --- docs/designs/argo.pandoc | 4 ++-- docs/designs/nested-svm-cpu-features.md | 12 ++++++------ docs/designs/qemu-deprivilege.md | 8 ++++---- docs/designs/xenstore-migration.md | 2 +- docs/features/qemu-deprivilege.pandoc | 2 +- 5 files changed, 14 insertions(+), 14 deletions(-)