minor edits

state_harmful.md

@@ -84,7 +84,7 @@ to serve our request... A classic chicken and egg problem.
 # The Stateless Laptop
 
 In this chapter a vision for the stateless laptop is described. The author
-believes the clean separation of state introduced by these modification would be
+believes the clean separation of state introduced by these modifications would be
 attractive not just on current x86-based platforms, but also on any future
 platforms, be they based on ARM or any other processor architectures.
 
@@ -151,7 +151,7 @@ flash chip is tasked with several crucial goals on modern Intel x86 laptops:
 
 1. It provides the firmware to the Intel ME processor. Failure to do so would,
    most likely, result in the platform shutdown.^[While there is no clear
-   officially statement in the Intel platform specs about this, it's considered
+   official statement in the Intel platform specs about this, it's considered
    a tribal knowledge among many experts.] 
 
 2. It provides the BIOS firmware. Failure to provide a valid BIOS firmware would
@@ -371,7 +371,7 @@ the speakers to communicate with other devices (such as the user's phone or even
 an internet-connected TV) in order to exfiltrate some low-bandwidth information
 (e.g. the disk decryption key stolen from the host DRAM page or registers).
 
-For this reason it seems only reasonably to put all the audio and video devices
+For this reason it seems only reasonable to put all the audio and video devices
 behind physical kill switches, just like it was recommended for all the wireless
 ones. Again it should be stressed the physical switches should be cutting the
 actual power or signal lines to the devices, accounting for potentially
@@ -382,7 +382,7 @@ misbehaving ones.
 Finally, one additional aspect of building a stateless laptop is to account for
 all the state accumulated in the _volatile_ memory, specifically DRAM and the
 processor internal SRAM used by the ME. Even though we're talking about volatile
-memory, it's a well know fact that residual information might remain there for a
+memory, it's a well known fact that residual information might remain there for a
 surprisingly long time [@coldboot_attack]. Additionally, the ME internal memory
 (SRAM) is believed to remain to be sustained despite platform normal shutdown
 state, as the ME is still in operation, albeit it might be in sleep mode (again,
@@ -862,12 +862,12 @@ mostly open source BIOS has been used. Such a BIOS will still likely need to
 execute the Intel FSP blob, and this blob would be the only place which might
 inject the malware].
 
-The author believe such a move would be extremely risky for a vendor like Intel.
+The author believes such a move would be extremely risky for a vendor like Intel.
 Again, we should remember that such malware insertion (by either the processor
 or FSP blob) could not be conditioned on any persistent state, and so would be
 subject to reply "attack". In other words, once the processor or the FSP got
-caught while pulling this off, it should be possible for the user to reproduce
-and demonstrate this malicious behaviour arbitrary number of times subsequently.
+caught while pulling this off, it should be possible for the user to subsequently reproduce and
+demonstrate this malicious behaviour an arbitrary number of times.
 
 Of course, Intel ME, or a malicious SMM, instead of injecting malware into the
 host memory, might chose a more subtle approach and instead only expose a
@@ -894,7 +894,7 @@ stateless laptop allows us to force the adversary into a very dangerous
 territory, requiring them to take high risk and also making the attack very
 complex.
 
-It's worth nothing, however, how we have silently started assuming that we need
+It's worth noting, however, how we have silently started assuming that we need
 to have a largely open source BIOS (so largely trustworthy), even on our
 stateless laptop. Needless to say, the coreboot project [@coreboot] is a natural
 candidate for such a BIOS, and we are very lucky there is such a project in the
@@ -998,7 +998,7 @@ is transparency, required to assure that our Trusted Stick indeed implements
 read-only protection for certain parts of the flash, as well as reliable
 encryption for other partitions, as discussed earlier in the paper.]
 
-Also it does not seem trivial to use the same one SPI chip to both serve the
+Also it does not seem trivial to use the same SPI chip to both serve the
 firmware (i.e.  ME, BIOS, other) to the host processor, and at the same time to
 also act as a flash provider to the EC, and optionally also to the internal
 disk. The primary reason for this might be lack of a good multiplexing mechanism
@@ -1121,7 +1121,7 @@ First, there is no such thing as an "ARM processor" -- rather ARM releases only
 a set of specifications and other IP, which are then licensed by various
 vendors, such as NVIDIA, Samsung, Texas Instruments, and so forth. These vendors
 then combine the licensed ARM IP with their own, creating unique final products:
-the actual processors, customary called System-on-Chips (SoCs).
+the actual processors, customarily called System-on-Chips (SoCs).
 
 This large diversity of "ARM processors", while undoubtedly beneficial in some
 aspects, is also problematic -- e.g. it presents multiple research targets for