From c47a53d034275071ad7f5771d66d2a4c6fa98428 Mon Sep 17 00:00:00 2001 From: Bradlee Speice Date: Sat, 16 Feb 2019 20:46:25 -0500 Subject: [PATCH] Better. --- _posts/2019-02-14-insane-allocators.md | 35 ++++++++++++++++---------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/_posts/2019-02-14-insane-allocators.md b/_posts/2019-02-14-insane-allocators.md index 2566b37..54318a5 100644 --- a/_posts/2019-02-14-insane-allocators.md +++ b/_posts/2019-02-14-insane-allocators.md @@ -1,7 +1,7 @@ --- layout: post title: "Insane Allocators: segfaults in safe Rust" -description: "\"Trusting trust\" with allocators." +description: "...and what it means to be \"safe.\"" category: rust, memory tags: [] --- @@ -63,16 +63,23 @@ pub extern "C" fn malloc(size: usize) -> *mut c_void { // for all subsequent allocations, corrupting the location. return ALLOC; } + // Note that we don't ever handle `free`; if the first object + // we allocate gets freed, the memory address being given + // to everyone becomes a "use-after-free" bug. } ``` +Because this implementation of `malloc` is intentionally broken, +every program run using this library will crash. And I mean *every* +program; if you use dynamic memory, you're going down. + So how is it possible to run the Rust compiler in this environment? -`LD_PRELOAD` applies to all programs, so running `ls` will also -lead to memory corruption and crashing! The answer is that `sudo` +`LD_PRELOAD` applies to all programs, so the compiler should also +encounter memory corruption and crash, right? The answer is that `sudo` deletes environment variables like `LD_PRELOAD` and -`LD_LIBRARY_PATH` when running commands; it's possible to -crash `sudo` in the same way by using our evil `malloc` -implementation. +`LD_LIBRARY_PATH` when running commands. While it is technically possible +to crash `sudo` in the same way using our evil `malloc` implementation, +the default policy is to delete these variables because of security concerns. Finally, why does Rust 1.31 work, and 1.32 fail? The answer is in the release notes: @@ -88,12 +95,12 @@ global allocator. Rust programs prior to 1.28 aren't subject to this # So what? -It should be made very clear: the code demonstrated here isn't a -security issue. "Safe" Rust programs are only crashing in these -circumstances because the memory allocator is intentionally lying to it. -Even in mission critical systems, there are a lot of concerns beyond memory allocation; the +I do want to clarify: the code demonstrated here isn't a +security issue, and doesn't call into question Rust's definition of "safe." +The code demonstrated here crashes because the memory allocator is lying to it. +Even in mission critical systems, there are a lot of concerns beyond allocators; the [F-35 Joint Strike Fighter coding standards](http://www.stroustrup.com/JSF-AV-rules.pdf) -don't even give it a full page. +give memory allocation about 10 sentences total. But this example does highlight an assumption of Rust's memory model that I haven't seen discussed much: **safe Rust is safe if, and only if, @@ -101,7 +108,9 @@ the allocator it relies on is "correct"**. And because writing a non-trivial all [fundamentally unsafe](https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#unsafety), safe Rust will always rely on unsafe Rust somewhere. -That all said, know that "safe" Rust can only claim to be safe because it stands +That all said, know that "safe" Rust can claim to be safe because it stands on the shoulders of incredible developers working on jemalloc, [kmalloc](https://linux-kernel-labs.github.io/master/labs/kernel_api.html#memory-allocation), -and others. +and others. Without being able to trust the allocators, we wouldn't +be able to trust the promise of safe Rust. So to all the people +who make the safety promises of Rust possible - thanks.