专栏名称: 程序员的那些事
最有影响力的程序员自媒体,关注程序员相关话题:IT技术、IT职场、在线课程、学习资源等。
目录
相关文章推荐
程序员的那些事  ·  脏话越多,代码越好! ·  4 天前  
OSC开源社区  ·  国行版“苹果牌AI”有望使用腾讯、字节大模型 ·  6 天前  
程序猿  ·  这是我见过最简单粗暴的辞职书了 ·  5 天前  
码农翻身  ·  程序员家长装备了一件秘密武器! ·  5 天前  
51好读  ›  专栏  ›  程序员的那些事

写了Rust不安全代码怎么办?特斯拉工程师支了三招

程序员的那些事  · 公众号  · 程序员  · 2024-12-24 08:17

正文

推荐关注↓

Rust 因其强大的安全性能而备受青睐,尤其是在内存安全和线程安全方面。然而,这是否意味着只要使用 Rust,就一定能避免编写出不安全的代码呢?事实并非如此。在某些场景下,开发者不得不使用 unsafe Rust 来完成任务,这也带来了潜在的安全隐患。那么,如何在这些不可避免的情况下,最大程度地降低风险,确保代码的可靠性呢?

特斯拉工程师 Colin Breck 针对此问题撰文,总结了三种有效的实践方法,希望能对开发者有所裨益。

原文:https://blog.colinbreck.com/making-unsafe-rust-a-little-safer-tools-for-verifying-unsafe-code/

作者 | Colin Breck       责编 | 苏宓
出品 | CSDN(ID:CSDNnews)

Rust 之所以能成为一种流行的系统编程语言,其中一个原因是它具有出色的性能,同时可以在编译时消除内存和并发错误,而这些错误在其他具有类似性能特性的语言(如 C 和 C++)中很难避免。不过,开发者可以通过编写 unsafe Rust 代码来绕过这些编译时检查。尽管绝大多数程序员不应编写不安全的 Rust 代码,但一些库出于性能需求、以及直接操作内存或硬件,或者与其他库和系统调用集成的目的,使用了不安全的 Rust 代码。

接下来,本文将探讨验证不安全 Rust 代码的工具,包括从 C 或 C++ 编写的库中调用的不安全代码。现下我想要深入这一主题,主要目的也是想为运营技术(OT)和关键基础设施编写安全且可靠的软件。

内存检测工具 Sanitizers

Sanitizers 是一种运行时工具,专门用来检测程序运行中的问题,比如内存损坏、内存泄漏或线程之间的数据竞争。它的工作原理是在编译代码时自动插入检查机制,帮助验证程序的行为是否正常。在使用 Sanitizers 时虽然它会引入内存和性能开销,但通常仅用于测试环境中。重要的是,与编译器不同,Sanitizer 只能检测在运行时实际被执行的代码路径中的错误——这可以通过测试或直接运行程序来实现。

当我第一次得知 Rust 支持用于查找错误的 Sanitizers 时,我感到很惊讶。因为过往,我比较熟悉如何在 C 和 C++ 中通过 Clang 和 LLVM 编译器使用 Sanitizers。由于 Rust 的编译器 rustc 也是基于 LLVM 构建的,它同样可以使用这些 Sanitizers。

内存越界访问/缓冲区溢出

看一下下面的程序:

fn bad_address(i: i32) -> i32 {    let xs: [i32; 4] = [0, 1, 2, 3];    xs[i as usize]}

fn main() { let v = bad_address(4); println!("Value at offset: {}", v);}

当我使用 RUST_BACKTRACE=1 cargo run --release 运行程序时,Rust 的边界检查检测到了错误,程序会 panic(崩溃):

thread 'main' panicked at src/main.rs:3:5:index out of bounds: the len is 4 but the index is 4stack backtrace:   0: _rust_begin_unwind   1: core::panicking::panic_fmt   2: core::panicking::panic_bounds_check   3: sanitizers::main

程序被终止,这种情况可能是开发者极不愿看到甚至是难以接受的,尤其当该软件对关键基础设施的运行至关重要时,可能会引发其他安全问题。然而,运行时检查可确保程序永远不会执行导致未定义行为的不安全代码。

现在考虑一种情况——如果该函数在一个 unsafe 代码块中使用指针索引数组会发生什么:

fn bad_address(i: i32) -> i32 {    let xs: [i32; 4] = [0, 1, 2, 3];    unsafe { *xs.as_ptr().offset(i as isize) }}
fn main() { let v = bad_address(4); println!("Value at offset: {}", v);}

在不安全代码中,Rust 编译器不再提供内存和线程安全的保障。程序员需要自己确保不安全代码是符合规则的,并且不会导致未定义行为。当我运行这段代码时,即使程序读取了数组边界外的内存,也不会触发 panic。

Value at offset: 24576

Rust 的 AddressSanitizer 可以帮忙检查代码中对堆栈和堆的越界访问。它的原理是,AddressSanitizer 通过在内存分配之间插入一些“红区”(red-zones),这些区域不能被访问,同时使用影子内存(shadow memory)追踪内存是否被非法读写。如果程序访问了不该碰的内存,AddressSanitizer 就会报错。需要注意的是,这个工具只能在 Rust 的 nightly 版本中使用,不能用在稳定版上。但别担心,nightly 和稳定版工具链可以同时安装,不会互相影响。要安装 nightly 工具链,你可以这样操作:

rustup install nightly

然后启动 AddressSanitizer 运行程序:

export RUSTFLAGS=-Zsanitizer=addresscargo +nightly run

程序会因为越界访问而崩溃,并生成详细的错误报告:

===================================================================96148==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016dce67b0 at pc 0x00010211bf70 bp 0x00016dce6770 sp 0x00016dce6768READ of size 4 at 0x00016dce67b0 thread T0    #0 0x00010211bf6c in array_out_of_bounds_unsafe::bad_address::h9a9dae85f9ad5feb array_out_of_bounds_unsafe.rs:3    #1 0x00010211c170 in array_out_of_bounds_unsafe::main::hc84cbff8319e0a2b array_out_of_bounds_unsafe.rs:7    #2 0x00010211bd40 in core::ops::function::FnOnce::call_once::hc75a52fb9134d583 function.rs:250    #3 0x00010211bd8c in std::sys::backtrace::__rust_begin_short_backtrace::h9c09c1d17c8393c3 backtrace.rs:152    #4 0x00010211b888 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h3a3a442dfff79e34 rt.rs:195    #5 0x000102135230 in std::rt::lang_start_internal::hc996363c321dd410+0x440 (array_out_of_bounds_unsafe:arm64+0x10001d230)    #6 0x00010211b6c0 in std::rt::lang_start::hae3ff67dcefd99eb rt.rs:194    #7 0x00010211c2e0 in main+0x20 (array_out_of_bounds_unsafe:arm64+0x1000042e0)    #8 0x00019d87e0dc  ()    #9 0xf4687ffffffffffc  ()

Address 0x00016dce67b0 is located in stack of thread T0 at offset 48 in frame #0 0x00010211bdbc in array_out_of_bounds_unsafe::bad_address::h9a9dae85f9ad5feb array_out_of_bounds_unsafe.rs:1

This frame has 1 object(s): [32, 48) 'xs' (line 2) <== Memory access at offset 48 overflows this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-buffer-overflow array_out_of_bounds_unsafe.rs:3 in array_out_of_bounds_unsafe::bad_address::h9a9dae85f9ad5febShadow bytes around the buggy address: 0x00016dce6500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x00016dce6780: f1 f1 f1 f1 00 00[f3]f3 00 00 00 00 00 00 00 00 0x00016dce6800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6880: 00 00 00 00 f1 f1 f1 f1 f8 f8 f2 f2 f8 f8 f8 f8 0x00016dce6900: f8 f8 f2 f2 f2 f2 04 f3 00 00 00 00 00 00 00 00 0x00016dce6980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016dce6a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==96148==ABORTING

上述这一示例是在 debug 模式下运行的。如果在 release 模式下运行,由于编译器优化,可能无法识别到该错误。因此,在 release 构建中使用 Sanitizer 时,务必禁用编译器优化:

export RUSTFLAGS="-C opt-level=0 -Zsanitizer=address"cargo +nightly run --release

值得一提的是,AddressSanitizer 不是每次都能发现内存越界的问题。在前面的例子中,程序的表现取决于我访问数组时用的索引值:程序可能正常运行,也可能因为访问了未知地址而报 SEGV 错误,或者因为堆栈溢出直接崩溃。

数据竞争

为了完整讨论 Sanitizer(检测工具),我还想分享另一个示例,讨论一下在不安全 Rust 代码中出现的错误可以通过 Sanitizer 检测到的方法。再来看一下以下代码,该代码从不同线程中的不安全代码访问共享的可变变量:

fn main() {    static mut A: usize = 0;

let t = std::thread::spawn(|| { unsafe { A += 1 }; }); unsafe { A += 1 };

t.join().unwrap();}

正常运行此程序不会产生运行时错误,但当启用 ThreadSanitizer 运行时,它会出现这种情况:

export RUSTFLAGS=-Zsanitizer=threadcargo +nightly run

它将检测到数据竞争并生成详细的报告:

==================WARNING: ThreadSanitizer: data race (pid=12331)  Read of size 8 at 0x000104f40460 by thread T1:    #0 sanitizers::main::_$u7b$$u7b$closure$u7d$$u7d$::h77c6a8d926b4ffd9 main.rs:5 (sanitizers:arm64+0x10000ae68)    #1 std::sys::backtrace::__rust_begin_short_backtrace::h3d7723e74dc43907 backtrace.rs:152 (sanitizers:arm64+0x100008f6c)    #2 std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h972cca723fc4d46a mod.rs:561 (sanitizers:arm64+0x1000033a4)    #3 _$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h339263acc4287c3b unwind_safe.rs:272 (sanitizers:arm64+0x100004e64)    #4 std::panicking::try::do_call::h1720a438c6154692 panicking.rs:573 (sanitizers:arm64+0x1000090b8)    #5 __rust_try  (sanitizers:arm64+0x10000351c)    #6 std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h4a9e1cb91e992611 mod.rs:559 (sanitizers:arm64+0x100002cf0)    #7 core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h4d54278169623269 function.rs:250 (sanitizers:arm64+0x100005254)    #8 std::sys::pal::unix::thread::Thread::new::thread_start::h5efa5b2bb0838bc2  (sanitizers:arm64+0x10002acd4)

Previous write of size 8 at 0x000104f40460 by main thread: #0 sanitizers::main::he9b6ca8696085c08 main.rs:7 (sanitizers:arm64+0x100004b9c) #1 core::ops::function::FnOnce::call_once::hba41c0d640901898 function.rs:250 (sanitizers:arm64+0x10000540c) #2 std::sys::backtrace::__rust_begin_short_backtrace::hc59209a0a1d24814 backtrace.rs:152 (sanitizers:arm64+0x10000901c) #3 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h915b5f69c928813d rt.rs:195 (sanitizers:arm64+0x100005148) #4 std::rt::lang_start_internal::hc996363c321dd410 (sanitizers:arm64+0x10002428c) #5 main (sanitizers:arm64+0x100004d6c)

Location is global 'sanitizers::main::A::h92ea287e34ba2e52' at 0x000104f40460 (sanitizers+0x100058460)

Thread T1 (tid=11227209, running) created by main thread at: #0 pthread_create (librustc-nightly_rt.tsan.dylib:arm64+0xa0a8) #1 std::sys::pal::unix::thread::Thread::new::h0b16ad3e3a52b1cf (sanitizers:arm64+0x10002ab38) #2 std::thread::Builder::spawn_unchecked::hbd40c84e3aa877bf mod.rs:467 (sanitizers:arm64+0x100002028) #3 std::thread::spawn::hd17317d53012bcc4 mod.rs:730 (sanitizers:arm64+0x100001fa0) #4 sanitizers::main::he9b6ca8696085c08 main.rs:4 (sanitizers:arm64+0x100004b54) #5 core::ops::function::FnOnce::call_once::hba41c0d640901898 function.rs:250 (sanitizers:arm64+0x10000540c) #6 std::sys::backtrace::__rust_begin_short_backtrace::hc59209a0a1d24814 backtrace.rs:152 (sanitizers:arm64+0x10000901c) #7 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h915b5f69c928813d rt.rs:195 (sanitizers:arm64+0x100005148) #8 std::rt::lang_start_internal::hc996363c321dd410 (sanitizers:arm64+0x10002428c) #9 main (sanitizers:arm64+0x100004d6c)

SUMMARY: ThreadSanitizer: data race main.rs:5 in sanitizers::main::_$u7b$$u7b$closure$u7d$$u7d$::h77c6a8d926b4ffd9==================ThreadSanitizer: reported 1 warnings

Miri

Rust 支持的一套 Sanitizer 工具在查找不安全代码错误方面非常有帮助,但它们不是万能的,无法找到所有错误。而且,这些 Sanitizer 工具之间并不完全兼容,每次只能单独运行,这会增加测试次数和耗费的时间。

Miri 是另一种工具,它是一个解释器,可以更准确地发现不安全代码中的问题,比如越界访问、内存泄漏、使用未初始化数据、释放后使用(use-after-free)以及数据竞争等。它的工作原理是解释 Rust 的中间表示(MIR),这种方式介于编译器的静态分析和 Sanitizer 的动态分析之间,更有针对性地发现潜在问题。

与 Sanitizer 类似,Miri 依赖于 Rust 的 nightly 工具链,安装也很简单:

rustup +nightly component add miri

内存越界访问

让我们重新考虑之前的越界内存访问示例:

fn bad_address(i: i32) -> i32 {    let xs: [i32; 4] = [0, 1, 2, 3];    unsafe { *xs.as_ptr().offset(i as isize) }}

fn main() { let v = bad_address(4000); println!("Value at offset: {}", v);}

使用 Miri 十分简单:

cargo +nightly miri run

它会报告越界访问错误并提供回溯信息:

error: Undefined Behavior: out-of-bounds pointer arithmetic: expected a pointer to 16000 bytes of memory, but got alloc870 which is only 16 bytes from the end of the allocation --> src/main.rs:3:15  |3 |     unsafe { *xs.as_ptr().offset(i as isize) }  |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ out-of-bounds pointer arithmetic: expected a pointer to 16000 bytes of memory, but got alloc870 which is only 16 bytes from the end of the allocation  |  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further informationhelp: alloc870 was allocated here: --> src/main.rs:2:9  |2 |     let xs: [i32; 4] = [0, 1, 2, 3];  |         ^^  = note: BACKTRACE (of the first span):  = note: inside `bad_address` at src/main.rs:3:15: 3:45note: inside `main` --> src/main.rs:7:13  |7 |     let v = bad_address(4000);  |             ^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

虽然 Sanitizer 也检测到了相同的错误,但 Miri 的输出更加具体,易于理解,包括代码片段而不是内存地址和栈帧。此外,Miri 在单次执行中检查多种未定义行为。与 Sanitizer 类似,Miri 只解释实际执行的代码路径(无论是在测试中还是在二进制程序运行时),并且不会发现未被解释的代码路径中的错误。

数据竞争

为了完整性,我再次使用存在数据竞争的代码,但这次使用 Miri 在测试中运行它:

fn data_race() {    static mut A: usize = 0;

let t = std::thread::spawn(|| { unsafe { A += 1 }; }); unsafe { A += 1 };

t.join().unwrap();}

#[cfg(test)]mod tests { use crate::data_race;

#[test] fn data_race_test() { data_race(); }}

执行 Miri 的测试命令如下:

cargo +nightly miri test

Miri 成功识别出数据竞争,并包含具体的代码片段和错误信息,比上面 Rust  ThreadSanitizer 的输出更易于理解:

running 1 testtest tests::data_race_test ... error: Undefined Behavior: Data race detected between (1) non-atomic write on thread `tests::data_race_test` and (2) non-atomic read on thread `unnamed-2` at alloc1. (2) just happened here --> src/main.rs:5:18  |5 |         unsafe { A += 1 };  |                  ^^^^^^ Data race detected between (1) non-atomic write on thread `tests::data_race_test` and (2) non-atomic read on thread `unnamed-2` at alloc1. (2) just happened here  |help: and (1) occurred earlier here --> src/main.rs:7:14  |7 |     unsafe { A += 1 };  |              ^^^^^^  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information  = note: BACKTRACE (of the first span) on thread `unnamed-2`:  = note: inside closure at src/main.rs:5:18: 5:24

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

C 和 C++ 库的情况

Miri 是一款非常实用的工具,但它还有一个限制:目前它无法解释通过 Rust 外部函数接口(FFI) 调用的代码,而 FFI 是 Rust 调用 C 和 C++ 库的方式。例如,rusqlite 用 FFI 调用 C 语言编写的 SQLite 数据库,duckdb-rs 通过用 FFI 调用了用 C++ 编写的 DuckDB,以及 open62541 调用用 C 语言编写的 OPC UA 库。由于 Miri 使用跨平台的解释器运行程序,程序无法访问 FFI 或大多数平台特定的 API。只有一些常见的功能,比如文件系统访问和标准输出打印,被 Miri 支持。

好消息是,我们可以返回使用 C 和 C++ 编译器(如 GCC 或 Clang)提供的 Sanitizer。关键在于,C 或 C++ 代码必须在调用前通过启动相应的 Sanitizer 进行编译,然后才能在 Rust 调用它。

观察下面 C 语言代码中的不安全示例:

#include #include 

void c_say_hello(const char *message) { char buffer[10]; strcpy(buffer, message); // Unsafe: no bounds checking! printf("Hello from C! %s\n", buffer);}

可以通过一个 build.rs 文件使用 Clang 编译 C 代码,并启用 AddressSanitizer:

fn main() {    let mut build = cc::Build::new();    build        .compiler("clang")        .file("c_src/c_code.c")        .flag("-Wall") // Enable warnings        .flag("-fsanitize=address") // Enable AddressSanitizer        .flag("-fno-omit-frame-pointer"); // Simplify stack tracing

build.compile("c_code");

// Ensure the build script reruns if the C file changes println!("cargo:rerun-if-changed=c_src/c_code.c");}

然后,可以使用 FFI 从不安全块中的 Rust 库调用 C 代码:

use std::ffi::{c_char, CString};
#[link(name = "c_code")] // Link to the compiled libraryextern "C" { fn c_say_hello(name: *const c_char);}
pub fn say_hello(message: &str) { let name = CString::new(message).expect("CString::new failed"); unsafe { c_say_hello(name.as_ptr()); // Call the C function }}

最后,可以在程序中调用包装 C 代码的“安全” Rust 函数:

use sanitizers::say_hello;
fn main() { say_hello("This is far too long and will do bad things!");}

在启用 AddressSanitizer 的情况下运行程序:

export RUSTFLAGS=-Zsanitizer=addresscargo +nightly run

它会报告栈缓冲区溢出错误:

===================================================================51935==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016fa7e76a at pc 0x000100c32ad0 bp 0x00016fa7e730 sp 0x00016fa7dee0WRITE of size 45 at 0x00016fa7e76a thread T0    #0 0x000100c32acc in strcpy+0x4ec (librustc-nightly_rt.asan.dylib:arm64+0x4aacc)    #1 0x000100383ee8 in c_say_hello+0x11c (sanitizers:arm64+0x100003ee8)    #2 0x000100383328 in sanitizers::say_hello::h7a86e3249bf087ea+0x1d8 (sanitizers:arm64+0x100003328)    #3 0x0001003815c0 in sanitizers::main::h11beac415f2c6ee0 main.rs:4    #4 0x0001003818d8 in core::ops::function::FnOnce::call_once::h6f36f80e70ecb8a5 function.rs:250    #5 0x000100381910 in std::sys::backtrace::__rust_begin_short_backtrace::h5a6edce2cadaf2f4 backtrace.rs:152    #6 0x000100381488 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h6d09ba155578db90 rt.rs:195    #7 0x00010039ccfc in std::rt::lang_start_internal::hc996363c321dd410+0x440 (sanitizers:arm64+0x10001ccfc)    #8 0x0001003812c0 in std::rt::lang_start::hf8df676e77f16e31 rt.rs:194    #9 0x0001003815ec in main+0x20 (sanitizers:arm64+0x1000015ec)    #10 0x00019d87e0dc  ()    #11 0xb922fffffffffffc  ()

Address 0x00016fa7e76a is located in stack of thread T0 at offset 42 in frame #0 0x000100383dd8 in c_say_hello+0xc (sanitizers:arm64+0x100003dd8)

This frame has 1 object(s): [32, 42) 'buffer' (line 5) <== Memory access at offset 42 overflows this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-buffer-overflow (librustc-nightly_rt.asan.dylib:arm64+0x4aacc) in strcpy+0x4ecShadow bytes around the buggy address: 0x00016fa7e480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x00016fa7e700: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00[02]f3 f3 0x00016fa7e780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e800: 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8 f2 f2 f2 f2 0x00016fa7e880: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x00016fa7e980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==51935==ABORTING

需要注意的是,错误是发生在调用 c_say_hello 函数里的 strcpy 函数时,也就是 C 的栈帧中。这说明通过 FFI 调用的 C 代码不再是“看不见的黑盒”,可以被检测到问题。如果你把这个例子中的 C 代码用普通方式编译(不加 AddressSanitizer,试着从 build.rs 文件里去掉相关的那一行),而 Rust 代码仍然用 AddressSanitizer 运行,那么程序还是会报错,提示栈缓冲区溢出(stack-buffer-overflow)。不过,这时错误信息会不那么具体,并且会显示问题出在 Rust 代码中,而不是 C 代码里。

结论

本文探讨了三种验证不安全 Rust 代码的技术,以提高代码安全性并避免可能带来严重后果的未定义行为。这些后果包括故障、安全漏洞、违反法规、经济损失、人员伤害甚至死亡。本文并非旨在进行详尽的调查,而是我为解决实际问题所探索的故事、推荐使用的工具。总结三种技术如下:

1. Sanitizer:在运行时检测不安全 Rust 代码;

2. Miri 解释器,用于检查不安全 Rust 代码;

3. C 和 C++ Sanitizer:在 Rust 中调用 C 和 C++ 库时进行运行时检测。

大多数系统程序员和应用开发者都不应编写不安全的 Rust 代码。不安全 Rust 主要应该属于库开发者的领域。但如果必须编写不安全代码,或者通过所依赖的库调用不安全代码,建议使用 Sanitizer 或 Miri 对代码进行测试,避免出现各种错误。


- EOF -

推荐阅读  点击标题可跳转

1、字节起诉前实习生,索赔 800 万

2、曾经对程序员最好的公司,撤退了

3、Linux 版微信选了这个 90 年代的“过气”框架

4、世界上最伟大最邪恶的软件发明,超10亿电脑安装

5、曾硬刚小米,估值 60 亿美元的独角兽被宣布破产


关注「程序员的那些事」加星标,不错过圈内事

点赞和在看就是最大的支持❤️