diff --git a/src/doc/rustc/src/exploit-mitigations.md b/src/doc/rustc/src/exploit-mitigations.md index d4e2fc52e97..f8bafe03214 100644 --- a/src/doc/rustc/src/exploit-mitigations.md +++ b/src/doc/rustc/src/exploit-mitigations.md @@ -42,8 +42,7 @@ understood within a given context. This section documents the exploit mitigations applicable to the Rust compiler when building programs for the Linux operating system on the AMD64 architecture -and equivalent.1 All examples in this section were built using +and equivalent.[^all-targets] All examples in this section were built using nightly builds of the Rust compiler on Debian testing. The Rust Programming Language currently has no specification. The Rust compiler @@ -67,11 +66,8 @@ equivalent. | Forward-edge control flow protection | Yes | Nightly | | Backward-edge control flow protection (e.g., shadow and safe stack) | Yes | Nightly | -1\. See - -for a list of targets and their default options. ↩ - +[^all-targets]: See + for a list of targets and their default options. ### Position-independent executable @@ -141,18 +137,15 @@ Integer overflow checks are enabled when debug assertions are enabled (see Fig. 3), and disabled when debug assertions are disabled (see Fig. 4). To enable integer overflow checks independently, use the option to control integer overflow checks, scoped attributes, or explicit checking methods such as -`checked_add`2. +`checked_add`[^checked-methods]. It is recommended that explicit wrapping methods such as `wrapping_add` be used when wrapping semantics are intended, and that explicit checking and wrapping methods always be used when using Unsafe Rust. -2\. See [the `u32` docs](../std/primitive.u32.html) for more -information on the checked, overflowing, saturating, and wrapping methods -(using u32 as an example). ↩ - +[^checked-methods]: See [the `u32` docs](../std/primitive.u32.html) for more + information on the checked, overflowing, saturating, and wrapping methods + (using u32 as an example). ### Non-executable memory regions @@ -180,17 +173,14 @@ binary. The presence of an element of type `PT_GNU_STACK` in the program header table with the `PF_X` (i.e., executable) flag unset indicates non-executable memory -regions3 are enabled for a given binary (see Fig. 5). +regions[^other-regions] are enabled for a given binary (see Fig. 5). Conversely, the presence of an element of type `PT_GNU_STACK` in the program header table with the `PF_X` flag set or the absence of an element of type `PT_GNU_STACK` in the program header table indicates non-executable memory regions are not enabled for a given binary. -3\. See the Appendix section for more information on why it -affects other memory regions besides the stack. ↩ - +[^other-regions]: See the [Appendix section](#appendix) for more information + on why it affects other memory regions besides the stack. ### Stack clashing protection @@ -270,8 +260,7 @@ $ readelf -d target/release/hello-rust | grep BIND_NOW Fig. 10. Checking if immediate binding is enabled for a given binary. The presence of an element with the `DT_BIND_NOW` tag and the `DF_BIND_NOW` -flag4 in the dynamic section indicates immediate binding +flag[^bind-now] in the dynamic section indicates immediate binding is enabled for a given binary (see Fig. 10). Conversely, the absence of an element with the `DT_BIND_NOW` tag and the `DF_BIND_NOW` flag in the dynamic section indicates immediate binding is not enabled for a given binary. @@ -281,9 +270,7 @@ table and of an element with the `DT_BIND_NOW` tag and the `DF_BIND_NOW` flag in the dynamic section indicates full RELRO is enabled for a given binary (see Figs. 9–10). -4\. And the `DF_1_NOW` flag for some link editors. ↩ - +[^bind-now]: And the `DF_1_NOW` flag for some link editors. ### Heap corruption protection @@ -303,8 +290,7 @@ Rust’s default allocator has historically been [jemalloc](http://jemalloc.net/), and it has long been the cause of issues and the subject of much discussion[32]–[38]. Consequently, it has been removed as the default allocator in favor of the operating system’s standard C library -default allocator5 since version 1.32.0 (2019-01-17)[39]. +default allocator[^linx-allocator] since version 1.32.0 (2019-01-17)[39]. ```rust,no_run fn main() { @@ -343,11 +329,9 @@ Fig. 13. Build and execution of hello-rust-heap with debug assertions disabled Heap corruption checks are performed when using the default allocator (i.e., the GNU Allocator) (see Figs. 12–13). -5\. Linux's standard C library default allocator is the GNU -Allocator, which is derived from ptmalloc (pthreads malloc) by Wolfram Gloger, -which in turn is derived from dlmalloc (Doug Lea malloc) by Doug Lea. ↩ - +[^linx-allocator]: Linux's standard C library default allocator is the GNU + Allocator, which is derived from ptmalloc (pthreads malloc) by Wolfram Gloger, + which in turn is derived from dlmalloc (Doug Lea malloc) by Doug Lea. ### Stack smashing protection @@ -385,8 +369,7 @@ commercially available [grsecurity/PaX Reuse Attack Protector (RAP)](https://grsecurity.net/rap_faq). The Rust compiler supports forward-edge control flow protection on nightly -builds[41]-[42] 6. +builds[41]-[42] [^win-cfg]. ```text $ readelf -s -W target/release/hello-rust | grep "\.cfi" @@ -401,10 +384,8 @@ of symbols suffixed with ".cfi" or the `__cfi_init` symbol (and references to `__cfi_check`) indicates that LLVM CFI is not enabled for a given binary (see Fig. 15). -6\. It also supports Control Flow Guard (CFG) on Windows (see -). ↩ - +[^win-cfg]: It also supports Control Flow Guard (CFG) on Windows (see + ). ### Backward-edge control flow protection @@ -431,8 +412,7 @@ Newer processors provide hardware assistance for backward-edge control flow protection, such as ARM Pointer Authentication, and Intel Shadow Stack as part of Intel CET. -The Rust compiler supports shadow stack for the AArch64 architecture7on +The Rust compiler supports shadow stack for the AArch64 architecture[^amd64-shadow] on nightly builds[43]-[44], and also supports safe stack on nightly builds[45]-[46]. @@ -447,9 +427,8 @@ enabled for a given binary. Conversely, the absence of the `__safestack_init` symbol indicates that LLVM SafeStack is not enabled for a given binary (see Fig. 16). -7\. The shadow stack implementation for the AMD64 architecture -and equivalent in LLVM was removed due to performance and security issues. ↩ +[^amd64-shadow]: The shadow stack implementation for the AMD64 architecture + and equivalent in LLVM was removed due to performance and security issues. ## Appendix