[llvm] Proofread CFIVerify.rst

Author: kazutakahirata

llvm/docs/CFIVerify.rst

@@ -10,7 +10,7 @@ Objective
 
 This document provides an overview of an external tool to verify the protection
 mechanisms implemented by Clang's *Control Flow Integrity* (CFI) schemes
-(``-fsanitize=cfi``). This tool, provided a binary or DSO, should infer whether
+(``-fsanitize=cfi``). This tool, given a binary or DSO, should infer whether
 indirect control flow operations are protected by CFI, and should output these
 results in a human-readable form.
 
@@ -22,12 +22,12 @@ Location
 ========
 
 This tool will be present as a part of the LLVM toolchain, and will reside in
-the "/llvm/tools/llvm-cfi-verify" directory, relative to the LLVM trunk. It will
+the ``/llvm/tools/llvm-cfi-verify`` directory, relative to the LLVM trunk. It will
 be tested in two methods:
 
 - Unit tests to validate code sections, present in
-  "/llvm/unittests/tools/llvm-cfi-verify".
-- Integration tests, present in "/llvm/tools/clang/test/LLVMCFIVerify". These
+  ``/llvm/unittests/tools/llvm-cfi-verify``.
+- Integration tests, present in ``/llvm/tools/clang/test/LLVMCFIVerify``. These
   integration tests are part of clang as part of a continuous integration
   framework, ensuring updates to the compiler that reduce CFI coverage on
   indirect control flow instructions are identified.
@@ -38,16 +38,16 @@ Background
 This tool will continuously validate that CFI directives are properly
 implemented around all indirect control flows by analysing the output machine
 code. The analysis of machine code is important as it ensures that any bugs
-present in linker or compiler do not subvert CFI protections in the final
+present in the linker or compiler do not subvert CFI protections in the final
 shipped binary.
 
 Unprotected indirect control flow instructions will be flagged for manual
-review. These unexpected control flows may simply have not been accounted for in
-the compiler implementation of CFI (e.g. indirect jumps to facilitate switch
+review. These unexpected control flows may not have been accounted for in
+the compiler implementation of CFI (e.g., indirect jumps to facilitate switch
 statements may not be fully protected).
 
 It may be possible in the future to extend this tool to flag unnecessary CFI
-directives (e.g. CFI directives around a static call to a non-polymorphic base
+directives (e.g., CFI directives around a static call to a non-polymorphic base
 type). This type of directive has no security implications, but may present
 performance impacts.
 
@@ -66,7 +66,7 @@ the disassembly. A control flow graph would be generated from a small buffer of
 the instructions surrounding the 'target' control flow instruction. If the
 target instruction is branched-to, the fallthrough of the branch should be the
 CFI trap (on x86, this is a ``ud2`` instruction). If the target instruction is
-the fallthrough (i.e. immediately succeeds) of a conditional jump, the
+the fallthrough (i.e., immediately succeeds) of a conditional jump, the
 conditional jump target should be the CFI trap. If an indirect control flow
 instruction does not conform to one of these formats, the target will be noted
 as being CFI-unprotected.
@@ -76,7 +76,7 @@ fallthrough of a conditional jump), if the target represents a vcall that takes
 arguments, these arguments may be pushed to the stack after the branch but
 before the target instruction. In these cases, a secondary 'spill graph' in
 constructed, to ensure the register argument used by the indirect jump/call is
-not spilled from the stack at any point in the interim period. If there are no
+not spilled from the stack at any point in the interim. If there are no
 spills that affect the target register, the target is marked as CFI-protected.
 
 Other Design Notes