Re: [PATCH] Design docs: Fix some typos in the design docs

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 15 Jan 2025, Frediano Ziglio wrote:
> On Wed, Jan 15, 2025 at 1:45 PM Bernhard Kaindl
> <bernhard.kaindl@xxxxxxxxx> 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@xxxxxxxxx>
> > ---
> >  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@xxxxxxxxx>

Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>