Fix typos/language issues in chapter 6

Author: yannickmoy

src/en/unsafe/ffi.md

@@ -74,7 +74,7 @@ fn main() {
 
 Typing is the way Rust ensures memory safety. When interfacing with other
 languages, which may not offer the same guarantee, the choice of types in the
-binding is essential to maintain the memory safety.
+binding is essential to maintain memory safety.
 
 ### Data layout
 
@@ -134,7 +134,7 @@ The following types are considered C-compatible:
 - an `Option<T>` where `T` is either
   - `core::ptr::NonNull<U>` and `U` is a `Sized` C-compatible type, then it is
       compatible to a `*const T` and `*mut T` pointer;
-  - `core::num::NonZero*`, then is compatible to the corresponding integral
+  - `core::num::NonZero*`, then is compatible with the corresponding integral
       primitive type;
 - a `repr(transparent)`-annotated `struct` with only one field, where that
   field has a C-compatible type.
@@ -146,9 +146,9 @@ The following types are not C-compatible:
 - Enums with fields,
 - Tuples (but `repr(C)` tuple structures are OK).
 
-Some types are compatibles with some caveats:
+Some types are compatible with some caveats:
 
-- Zero-sized types, which is really zero sized (which is let unspecified in C
+- Zero-sized types, which is really zero sized (which is left unspecified in C
   and contradicts the C++ specification),
 - `repr(C)`, `repr(C, Int)`, or `repr(Int)`-annotated enum with fields
   (see [RFC 2195]).
@@ -219,7 +219,7 @@ the C standard library.
 >
 > In a secure Rust development, when interfacing with foreign code that
 > uses platform-dependent types, such as C's `int` and `long`, Rust code must
-> use portable type aliases, such as provided by the standard library or the
+> use portable type aliases, such as the ones provided by the standard library or the
 > [libc] crate, rather than platform-specific types, except if
 > the binding is automatically generated for each platform (see Note below).
 
@@ -255,23 +255,23 @@ the C-compatible types:
 - references,
 - function pointers,
 - enums,
-- floats (even if almost every language have the same understanding of what is
+- floats (even if almost all languages have the same understanding of what is
   a valid float),
 - compound types that contain a field of a non-robust type.
 
 On the other hand, integer types (`u*`/`i*`), packed compound types that contain
-no non-robust fields, for instance are *robust types*.
+no non-robust fields, are instances of *robust types*.
 
 Non-robust types are a difficulty when interfacing two languages. It revolves
-into deciding **which language of the two is responsible in asserting the
+around deciding **which language of the two is responsible for asserting the
 validity of boundary-crossing values** and how to do it.
 
 > **Rule {{#check FFI-CKNONROBUST | Do not use unchecked non-robust foreign values}}**
 >
 > In a secure Rust development, there must not be any use of *unchecked* foreign
 > values of non-robust types.
 >
-> In other words, either Rust translates robust types to non-robust types
+> In other words, either Rust translates robust types into non-robust types
 > through explicit checking or the foreign side offers strong guarantees of the
 > validity of the value.
 
@@ -283,7 +283,7 @@ validity of boundary-crossing values** and how to do it.
 > be done in Rust when possible.
 
 Those generic rules are to be adapted to a specific foreign language or for the
-associated risks. Concerning languages, C is particularly unfit to offer
+associated risks. Concerning languages, C is particularly unfit for offering
 guarantees about validity. However, Rust is not the only language to offer
 strong guarantees. For instance, some C++ subset (without reinterpretation)
 allows developers to do lot of type checking. Because Rust natively separates
@@ -293,7 +293,7 @@ function references, and enums, and are discussed below.
 
 > **Warning**
 >
-> Rust's `bool` has been made equivalent to C99's `_Bool` (aliased as `bool`
+> Rust `bool` has been made equivalent to C99's `_Bool` (aliased as `bool`
 > in `<stdbool.h>`) and C++'s `bool`. However, loading a value other than 0 and
 > 1 as a `_Bool`/`bool` is an undefined behavior *on both sides*.
 > Safe Rust ensures that. Standard-compliant C and C++ compilers ensure that no
@@ -305,7 +305,7 @@ function references, and enums, and are discussed below.
 #### References and pointers
 
 Although they are allowed by the Rust compiler, the use of Rust references in
-FFI may break Rust's memory safety. Because their “unsafety” is more explicit,
+FFI may break Rust memory safety. Because their “unsafety” is more explicit,
 pointers are preferred over Rust references when binding to another language.
 
 On the one hand, reference types are very non-robust: they allow only pointers
@@ -324,16 +324,16 @@ Rust references may be used reasonably with other C-compatible languages
 including C variants allowing for non-null type checking, e.g. Microsoft SAL
 annotated code.
 
-On the other hand, Rust's *pointer types* may also lead to undefined behaviors
+On the other hand, Rust *pointer types* may also lead to undefined behaviors
 but are more verifiable, mostly against `std/core::ptr::null()` (C's `(void*)0`)
-but also in some context against a known valid memory range (particularly in
+but also in some contexts against a known valid memory range (particularly in
 embedded systems or kernel-level programming). Another advantage of using Rust
 pointers in FFI is that any load of the pointed value is clearly marked inside
 an `unsafe` block or function.
 
 > **Recommendation {{#check FFI-NOREF | Do not use reference types but pointer types}}**
 >
-> In a secure Rust development, the Rust code should not use references types
+> In a secure Rust development, the Rust code should not use reference types
 > but pointer types.
 >
 > Exceptions include:
@@ -349,11 +349,11 @@ an `unsafe` block or function.
 
 > **Rule {{#check FFI-CKREF | Do not use unchecked foreign references}}**
 >
-> In a secure Rust development, every foreign references that is transmitted to
+> In a secure Rust development, every foreign reference that is transmitted to
 > Rust through FFI must be **checked on the foreign side** either automatically
 > (for instance, by a compiler) or manually.
 > 
-> Exceptions include Rust references in an opaque wrapping that is created
+> Exceptions include Rust references in an opaque wrapping that are created
 > and manipulated only from the Rust side and `Option`-wrapped references
 > (see Note below).
 
@@ -365,7 +365,7 @@ an `unsafe` block or function.
 > pointer must check their validity beforehand.
 > In particular, pointers must be checked to be non-null before any use.
 >
-> Stronger approaches are advisable when possible. They includes checking
+> Stronger approaches are advisable when possible. They include checking
 > pointers against known valid memory range or tagging (or signing) pointers
 > (particularly applicable if the pointed value is only manipulated from Rust).
 
@@ -415,7 +415,7 @@ int main() {
 #### Function pointers
 
 Function pointers that cross FFI boundaries may ultimately lead to arbitrary code
-execution and represents a real security risks.
+execution and represent a real security risks.
 
 > **Rule {{#check FFI-MARKEDFUNPTR | Mark function pointer types in FFI as `extern` and `unsafe`}}**
 >
@@ -458,8 +458,8 @@ possibilities:
 > In a secure Rust development, any foreign function pointer must be checked at
 > the FFI boundary.
 
-When binding with C or even C++, one cannot guarantee easily the validity of the
-function pointer. C++ functors are not C-compatible.
+When binding with C or even C++, one cannot guarantee easily the validity of 
+function pointers. C++ functors are not C-compatible.
 
 #### Enums
 
@@ -469,14 +469,14 @@ respect to the number of possible bit patterns of the same size. Mishandling an
 severe consequences on software security. Unfortunately, checking an `enum`
 value at the FFI boundary is not simple on both sides.
 
-On the Rust side, it consists to actually use an integer type in the `extern`
-block declaration, a *robust* type, and then to perform a checked conversion
+On the Rust side, it consists in actually using an integer type in the `extern`
+block declaration, a *robust* type, and then performing a checked conversion
 to the enum type.
 
 On the foreign side, it is possible only if the other language allows for
 stricter checks than plain C. `enum class` in C++ are for instance allowable.
-Note however that as for reference the actual `extern "C"` ABI of
-`enum class` is implementation defined and should be verified for each
+Note however that as for a reference, the actual `extern "C"` ABI of
+`enum class` is implementation-defined and should be verified for each
 environment.
 
 > **Recommendation {{#check FFI-NOENUM | Do not use incoming Rust `enum` at FFI boundary}}**
@@ -490,8 +490,8 @@ environment.
 >   Rust side,
 > - bound to safe enums in the foreign language, e.g. `enum class` types in C++.
 
-Concerning fieldless enums, crates like [`num_derive`] or [`num_enum`] allows
-developer to easily provide safe conversion from integer to enumeration and may
+Concerning fieldless enums, crates like [`num_derive`] or [`num_enum`] allow
+developers to easily provide safe conversions from integer to enumeration and may
 be use to safely convert an integer (provided from a C `enum`) into a Rust enum.
 
 [num_derive]: https://crates.io/crates/num_derive
@@ -517,7 +517,7 @@ extern "C" {
 }
 ```
 
-The not yet implemented [RFC 1861] proposes to facilitate the coding by allowing
+The not-yet-implemented [RFC 1861] proposes to facilitate this encoding by allowing
 to declare opaque types in `extern` blocks.
 
 [RFC 1861]: https://rust-lang.github.io/rfcs/1861-extern-types.html
@@ -526,7 +526,7 @@ to declare opaque types in `extern` blocks.
 >
 > In a secure Rust development, when interfacing with C or C++, Rust types that
 > are to be considered opaque in C/C++ should be translated as incomplete
-> `struct` type (i,e., declared without definition) and be provided with
+> `struct` types (i,e., declared without definition) and be provided with
 > a dedicated constructor and destructor.
 
 Example of opaque Rust type:
@@ -604,7 +604,7 @@ wrapper around the foreign type:
 > In a secure Rust development, any non-sensitive foreign piece of data that are
 > allocated and deallocated in the foreign language should be encapsulated in a
 > `Drop` type in such a way as to provide automatic deallocation in Rust,
-> through an automatic call to the foreing language deallocation routine.
+> through an automatic call to the foreign language deallocation routine.
 
 A simple example of Rust wrapping over an external opaque type:
 
@@ -664,18 +664,18 @@ impl Drop for Foo {
 > is not sufficient for sensitive deallocation (such as wiping sensitive data)
 > except if the code is guaranteed to never panic.
 >
-> For wiping sensitive data case, one could address the issue with a dedicated
+> For wiping sensitive data, one could address the issue with a dedicated
 > panic handler.
 
 When the foreign language is the one exploiting Rust allocated resources, it is
 a lot more difficult to offer any guarantee.
 
-In C for instance there is no easy way to check that the appropriate destructor
-is checked. A possible approach is to exploit callbacks to ensure that the
+In C for instance, there is no easy way to check that the appropriate destructor
+is called. A possible approach is to exploit callbacks to ensure that the
 reclamation is done.
 
 The following Rust code is a **thread-unsafe** example of a C-compatible API
-that provide callback to ensure safe resource
+that provides a callback to ensure safe resource
 reclamation:
 
 ```rust,noplaypen

src/en/unsafe/generalities.md

@@ -2,7 +2,7 @@
 
 ## *Unsafe* capacities
 
-Language capabilities can be extended using unsafe code. The full list of these capacities is given in the [Rust reference](https://doc.rust-lang.org/reference/unsafety.html). Notice the following one's.
+Language capabilities can be extended using unsafe code. The full list of these capacities is given in the [Rust reference](https://doc.rust-lang.org/reference/unsafety.html). Notice the following ones.
 
 * Dereference a raw pointer
 * Modify a static mutable variable
@@ -36,14 +36,14 @@ manipulations of memory pointers, the language provides the `unsafe` keyword.
 
 > **Rule {{#check LANG-UNSAFE | Don't use unsafe blocks}}**
 >
-> For a secured development, the `unsafe` blocks must be avoided. Afterward,
+> In a secure Rust development, the `unsafe` blocks must be avoided. In the following,
 > we list the only cases where `unsafe` may be used, provided that they come
 > with a proper justification:
 >
->  - The Foreign Function Interface (FFI) of Rust allows for describing
+>  - The Foreign Function Interface (FFI) of Rust allows describing
 >  functions whose implementations are written in C, using the `extern "C"`
 >  prefix. To use such a function, the `unsafe` keyword is required. “Safe”
->  wrapper shall be defined to safely and seamlessly call C code.
+>  wrappers shall be defined to safely and seamlessly call C code.
 >
 >  - For embedded device programming, registers and various other resources are
 >  often accessed through a fixed memory address. In this case, `unsafe` blocks
@@ -121,14 +121,14 @@ Consequently, even *safe* function must be handled carefully in *unsafe* context
 
 #### Example
 
-Suppose one wants to propose an API find object of a given type in the memory.
+Suppose one wants to propose an API to find objects of a given type in the memory.
 This API could ask implementing the following trait
 
 ```rust
 trait Locatable {
-    /// Find object of type `Self` in the buffer `buf`.
-    /// Returns the index of the first byte representing
-    /// an object of type `Self`
+    /// Find objects of type `Self` in the buffer `buf`.
+    /// Return the index of the first byte representing
+    /// an object of type `Self`.
     fn locate_instance_into(buf: &[u8]) -> Option<usize>;
 }
 ```
@@ -167,11 +167,11 @@ fn locate<T: Locatable + Clone>(start: *const u8, len: usize) -> Option<T> {
 This implementation is harmful for two reasons:
 
 * If the `Locatable` implementation gives the wrong index, the `as_ref` function produce an *UB*.
-* If the `Locatable` implementation gives an outbound index, the subsequent buffer overflow is an *UB*.
+* If the `Locatable` implementation gives an out-of-bounds index, the subsequent buffer overflow is an *UB*.
 
 </div>
 
-For instance, the following `Locatable` implementation is wrong **but** it is of the responsibility of the API maker to take it into account.
+For instance, the following `Locatable` implementation is wrong **but** it is the responsibility of the API maker to take it into account.
 
 ```rust
 impl Locatable for bool {
@@ -181,7 +181,7 @@ impl Locatable for bool {
 }
 ```
 
-The following program produces *UB*.
+The following program produces a *UB*.
 
 ```rust,should_panic
 fn main() {
@@ -246,7 +246,7 @@ in case these *safe* functions have bad behavior.
 If they cannot protect their function against badly implemented *safe* functions/traits, they could either
 
 * mark the function they *write* as `unsafe`: thus it is the user's responsibility to feed this function with correct arguments (by checking *unsafe* function documentation).
-* mark the traits they *use* as `unsafe` : thus it is user's responsibility to simplement the trait properly (again reading the trait documentation).
+* mark the traits they *use* as `unsafe` : thus it is user's responsibility to implement the trait properly (again reading the trait documentation).
 
 #### Références
 

src/en/unsafe/memory.md

@@ -39,7 +39,7 @@ forget(s); // Leak memory
 ```
 
 In particular, using `forget` may result in not releasing critical resources
-leading to deadlocks or not erasing sensitive data from the memory. That is why,
+leading to deadlocks or not erasing sensitive data from the memory. This is why
 `forget` is **unsecure**.
 
 > **Rule {{#check MEM-FORGET | Do not use `forget`}}**
@@ -86,9 +86,9 @@ compiler to the developer.
 
 ## Raw pointers
 
-This pointers are mainly used to use C pointer. They do not have the same protections
-than *smart pointers* and often have to be used in `unsafe` context. For instance, freeing 
-raw pointer must be done manually without Rust warranties.
+These pointers are mainly used for C pointers. They do not have the same protections
+as *smart pointers* and often have to be used in `unsafe` context. For instance, freeing 
+raw pointers must be done manually without Rust guaranties.
 
 > **Rule {{#check MEM-NORAWPOINTER | Do no convert smart pointer into raw pointer in Rust without `unsafe`}}**
 >
@@ -118,12 +118,13 @@ raw pointer must be done manually without Rust warranties.
 > let _ = unsafe { Box::from_raw(raw_ptr) }; // will be freed
 > ```
 
-Converse is true! That is `from_raw` should be call **only** on `into_raw`ed value. For instance,
-`Rc` smart pointer [explicitly request for this condition](https://doc.rust-lang.org/std/rc/struct.Rc.html#method.from_raw)
-and, for `Box` smart pointer, conversion of C pointer into `Box` is [discouraged](https://doc.rust-lang.org/std/boxed/index.html#memory-layout).
+The converse is also true! That is, `from_raw` should be call **only** on `into_raw`ed value. For instance,
+`Rc` smart pointers [explicitly request for this condition](https://doc.rust-lang.org/std/rc/struct.Rc.html#method.from_raw)
+and, for `Box` smart pointers, conversion of C pointers into `Box` is [discouraged](https://doc.rust-lang.org/std/boxed/index.html#memory-layout).
 
-> **Règle {{#check MEM-INTOFROMRAW | Call `from_raw` *only* on `into_raw`ed value}}**
-> In a secure Rust development, `from_raw` should only be called on `into_raw`ed value
+> **Rule {{#check MEM-INTOFROMRAW | Call `from_raw` *only* on `into_raw`ed value}}**
+>
+> In a secure Rust development, `from_raw` should only be called on `into_raw`ed values.
 
 <!-- -->
 
@@ -151,7 +152,7 @@ and, for `Box` smart pointer, conversion of C pointer into `Box` is [discouraged
 ## Uninitialized memory
 
 By default, Rust forces all values to be initialized, preventing the use of
-uninitialized memory (except if using `std::mem::uninitialized` or
+uninitialized memory (except when using `std::mem::uninitialized` or
 `std::mem::MaybeUninit`).
 
 > **Rule {{#check MEM-UNINIT | Do not use uninitialized memory}}**
@@ -170,14 +171,14 @@ The use of uninitialized memory may result in two distinct security issues:
 > `std::mem::MaybeUninit` is an improvement over `std::mem::uninitialized`.
 > Indeed, it makes dropping uninitialized values a lot more difficult.
 > However, it does not change the second issue: the non-drop of an initialized
-> memory is as much likely. It is problematic, in particular when considering
+> memory remains. It is problematic, in particular when considering
 > the use of `Drop` to erase sensitive memory.
 
 ## Cyclic reference counted pointers (`Rc` and `Arc`)
 
-Combining [interior mutability](https://doc.rust-lang.org/reference/interior-mutability.html), recurcivity and reference counted pointer into type definitions is unsafe. It can produce memory leaks which can result in DDoS attack or secret leaks.
+Combining [interior mutability](https://doc.rust-lang.org/reference/interior-mutability.html), recursivity and reference counted pointer into type definitions is unsafe. It can produce memory leaks which can result in DDoS attacks or leaking secrets.
 
-The following example show such a memory leak in safe Rust:
+The following example shows such a memory leak in safe Rust:
 
 ```rust
 use std::{cell::Cell, rc::Rc};
@@ -235,6 +236,6 @@ Hello, world!
 ==153637== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
 ```
 
-> **Règle {{#check MEM-MUT-REC-RC | Avoid cyclic reference counted pointers}}**
+> **Rule {{#check MEM-MUT-REC-RC | Avoid cyclic reference counted pointers}}**
 >
-> Avoid recursive types whose recursivity use reference counted pointers together with interior mutability.
+> Avoid recursive types whose recursivity uses reference counted pointers together with interior mutability.