Skip to content

Switch exploit mitigations to mdbook footnotes #140051

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 21, 2025
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 22 additions & 43 deletions src/doc/rustc/src/exploit-mitigations.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.<sup id="fnref:1" role="doc-noteref"><a href="#fn:1"
class="footnote">1</a></sup> 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
Expand All @@ -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 |

<small id="fn:1">1\. See
<https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec>
for a list of targets and their default options. <a href="#fnref:1"
class="reversefootnote" role="doc-backlink">↩</a></small>

[^all-targets]: See <https://github.com/rust-lang/rust/tree/master/compiler/rustc_target/src/spec>
for a list of targets and their default options.

### Position-independent executable

Expand Down Expand Up @@ -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`<sup id="fnref:2" role="doc-noteref"><a href="#fn:2"
class="footnote">2</a></sup>.
`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.

<small id="fn:2">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). <a href="#fnref:2" class="reversefootnote"
role="doc-backlink">↩</a></small>

[^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

Expand Down Expand Up @@ -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
regions<sup id="fnref:3" role="doc-noteref"><a href="#fn:3"
class="footnote">3</a></sup> 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.

<small id="fn:3">3\. See the Appendix section for more information on why it
affects other memory regions besides the stack. <a href="#fnref:3"
class="reversefootnote" role="doc-backlink">↩</a></small>

[^other-regions]: See the [Appendix section](#appendix) for more information
on why it affects other memory regions besides the stack.

### Stack clashing protection

Expand Down Expand Up @@ -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`
flag<sup id="fnref:4" role="doc-noteref"><a href="#fn:4"
class="footnote">4</a></sup> 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.
Expand All @@ -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).

<small id="fn:4">4\. And the `DF_1_NOW` flag for some link editors. <a
href="#fnref:4" class="reversefootnote" role="doc-backlink">↩</a></small>

[^bind-now]: And the `DF_1_NOW` flag for some link editors.

### Heap corruption protection

Expand All @@ -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 allocator<sup id="fnref:5" role="doc-noteref"><a href="#fn:5"
class="footnote">5</a></sup> 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() {
Expand Down Expand Up @@ -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).

<small id="fn:5">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. <a
href="#fnref:5" class="reversefootnote" role="doc-backlink">↩</a></small>

[^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

Expand Down Expand Up @@ -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] <sup id="fnref:6" role="doc-noteref"><a href="#fn:6"
class="footnote">6</a></sup>.
builds[41]-[42] [^win-cfg].

```text
$ readelf -s -W target/release/hello-rust | grep "\.cfi"
Expand All @@ -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).

<small id="fn:6">6\. It also supports Control Flow Guard (CFG) on Windows (see
<https://github.com/rust-lang/rust/issues/68793>). <a href="#fnref:6"
class="reversefootnote" role="doc-backlink">↩</a></small>

[^win-cfg]: It also supports Control Flow Guard (CFG) on Windows (see
<https://github.com/rust-lang/rust/issues/68793>).

### Backward-edge control flow protection

Expand All @@ -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 architecture<sup
id="fnref:7" role="doc-noteref"><a href="#fn:7" class="footnote">7</a></sup>on
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].

Expand All @@ -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).

<small id="fn:7">7\. The shadow stack implementation for the AMD64 architecture
and equivalent in LLVM was removed due to performance and security issues. <a
href="#fnref:7" class="reversefootnote" role="doc-backlink">↩</a></small>
[^amd64-shadow]: The shadow stack implementation for the AMD64 architecture
and equivalent in LLVM was removed due to performance and security issues.


## Appendix
Expand Down
Loading