fix various typos and formatting issues

blueprints/AMD_Grub_Late_Launch.md

@@ -9,7 +9,7 @@ SKINIT instruction.
 ## Background
 
 The AMD SKINIT instruction is a means to initiate a "late launch" that
-establishes a Dynamic Root of Trust Measuremnt (DRTM). The instruction call
+establishes a Dynamic Root of Trust Measurement (DRTM). The instruction call
 requires the system to be in a specific state as enumerated below,
  * SVM check, either the `EFER.SVME` bit is set to 1 or the feature flag `CPUID
    Fn8000_0001_ECX[SKINIT]` is set to 1
@@ -21,10 +21,10 @@ requires the system to be in a specific state as enumerated below,
 Grub will be extended with the following capabilities,
  * An SKINIT relocator that will,
   1. set protected mode
-  2. enalbe apic
+  2. enable APIC
   3. verify no machine check in progress
   4. clear machine check regs
-  5. skinit as final instruction
+  5. SKINIT as final instruction
  * A late launch loader that will,
   1. load kernel starting at 0x100000, compatibility with a Linux Secure Loader
   2. verify SVM is supported

documentation/Architecture.md

@@ -17,7 +17,7 @@ given control over the system.
 
 # TrenchBoot Security Engine
 
-At the heart of the TrencBoot Loader is the TrenchBoot Security Engine.  The
+At the heart of the TrenchBoot Loader is the TrenchBoot Security Engine.  The
 Security Engine is responsible for processing any evidence collected by the
 BITs, collect new evidence as needed, evaluate all evidence according to
 security policy, and execute appropriate enforcement actions. The components
@@ -31,7 +31,7 @@ below.
 A core concept in TrenchBoot is that of evidence. For TrenchBoot, evidence is a
 record of an event that occurred within the system. The typical form for these
 records is a cryptographic hash of system state that was the result of this
-event. This cryptographic hash is often referred to as a measurement. 
+event. This cryptographic hash is often referred to as a measurement.
 
 ## Boot Integrity Technology
 

documentation/DevelopersGuide.md

@@ -9,7 +9,7 @@ build system used to compose TrenchBoot launchable images.
 ## TrenchBoot Linux/uroot Configuration
 
 A TrenchBoot launchable image consists of a TrenchBoot Linux kernel with a
-TrenchBoot uroot initramfs embedded within the image. When building for a target,
+TrenchBoot u-root initramfs embedded within the image. When building for a target,
 the boot capabilities and BITs that will be supported will result in different
 launchable images. The diagram below provides a simple visual depiction of this
 setup.

documentation/UseCases.md

@@ -5,7 +5,7 @@ TrenchBoot is meant to be a universal framework to enable building integrity in
 the launch process of systems. To relate to real world usage, it is good to
 have a set of use cases that explain a subset of situations where TrenchBoot is
 applicable and how it would work in those situations. Below are a series of use
-cases that are actively being investigated and/or worked on. 
+cases that are actively being investigated and/or worked on.
 
 
 ## Crowd Sourcing Integrity
@@ -24,7 +24,7 @@ Authority (ACA).
 
 An individual or enterprise may not want to allow a system to boot on to their
 network unless it is running a known configuration. When TrenchBoot is
-installed onto a system it will work in conjunction with a Trenchboot ACA
+installed onto a system it will work in conjunction with a TrenchBoot ACA
 (public or private instance) that provides a key management service. TrenchBoot
 will hold a potion of a Shamir Secret Sharing key with another portion held by
 the key management service. For the system to boot it will attest to key
@@ -35,11 +35,10 @@ disk.
 
 Will traveling there are times when an individual looses positive control of
 their device. During these times attackers can launch physical access attacks.
-For this configuration TrenchBoot will "double chain wrap" the encryption key for
-decrypting the system where each chain wrap correlates to an authentication
-factor. Working internal to external, the system drive key is encrypted with the
-first wrap
-key that is in turned encrypted with the second wrap key. The first wrap key is
-stored on a removable token device, e.g. YubiKey, and the second wrap key is
-sealed in a TPM NVRAM slot. For a system to boot it must have launched with the
-correct firmware and the token must be present.
+For this configuration TrenchBoot will "double chain wrap" the encryption key
+for decrypting the system where each chain wrap correlates to an authentication
+factor. Working internal to external, the system drive key is encrypted with
+the first wrap key that is in turned encrypted with the second wrap key. The
+first wrap key is stored on a removable token device, e.g. YubiKey, and the
+second wrap key is sealed in a TPM NVRAM slot. For a system to boot it must
+have launched with the correct firmware and the token must be present.