what's so safe about unsafe rust?

wanna learn how computers work? learn to code at lowlevel.academy/ (get 20% with offer code ARMASSEMBLY20)

Great video, and I'd like to reinforce your comments on the merits of unsafe rust. When we work on audits of rust code, we specifically look for unsafe rust first and give the most attention to that, because it is the most likely place for the serious issues within many open source rust projects.

Miri is extremely useful! when I was porting an existing C program, miri ended up catching multiple vulnerabilities that otherwise produced no noticeable side effects when running an existing test suite. Genuinely a gamechanger when writing unsafe code.

honestly, I am by far more concerned about supply chain attacks, which I feel like are more probable to be exploited, have a bigger impact and need less cognitive effort compared to memory vulnerabilities. The sheer amount of libraries used in rust due to user friendly cargo - compared to C/C++ is somewhat scary to me

one thing I think you could have mentioned: Even when writing a good chunk of unsafe code in rust, the LSP rust-analyzer does a pretty good job of giving you a whole lot of warnings when you're trying to do the more "questionable" things you can do inside an unsafe block, it really is a powerful tool to avoid undefined behavior.

Since you mentioned you have never played with Miri, I'll take this opportunity to say that Miri immediately detects the use-after-free that cve-rs generates despite the fact that it's exploiting a compiler bug. :D

Is it possible to have a useful system level lang where you can’t do anything unsafe? So couldn’t deref raw pointers, allocate mem on the heap, etc. I thought the rust unsafe keywords purpose was to create safe wrappers around inherently unsafe code like a vectors get method which is safe because even though it’s trying to read a pointer at any index, it returns None if it’s out of bounds creating a safe interface around a unsafe thing (reading a raw pointer at any index). I just don’t think it’s possible to have a truly 100% memory safe system lang

If anyone wants to do more reading on this, "Rust for Rustaceans" by Jon Gjengset has a fantastic section on unsafe Rust. The rest of the book is also great!

From what I know, the windows crate is a gigantic crate in terms of code size, mostly since it's all generated from windows interface definitions, for all possible windows APIs you could think of (of which there are far more than of eg the linux kernel, since Windows APIs are concerned with more than just the kernel, and also Windows retains backward compatibility for far longer). So yeah, combine that with it being fundamentally FFI calls with a C (like) ABI, it's not really that remarkable that it has the most uses of unsafe of all crates.

The only reason you like Rust is the safety? Hmm... I honestly don't care all that much about the whole safety thing. It's everything else I really like. Sum types, blocks as expressions, traits, etc. It's like the language was designed for me, I like (almost) everything about it. It also has all the features I've been wanting in other languages (most notably sum types and powerful pattern matching/destructuring)

"34.35% of crates make a direct function call into another crate that uses the unsafe keyword" – remember tokio has to use unsafe to make use of the context api which is necessary for async runtimes. Additionally, if you're doing anything with Pin<...>, you pretty much have to use pin_project or something similar, which has unsafe under the hood as well. BTW there is an interesting question of methodology: let's consider crate like pin_project: the crate itself just exports a macro and doesn't contain any unsafe code by itself, but the code the macro expands to does contain unsafe, how is it counted? Does the crate using pin_project contain unsafe according to this methodology?

You know what would be cool? If the OS running the executable could tell you which unsafe block it was in when something crashed, because the compiler left them all labeled and it tracks every time an unsafe block is entered

Starts off implying that the 'unsafe' keyword stops the borrow checker. Hmm... OK the rest of the video turned out much better than that opening laid out. Zig is my chosen language the past few months but I wouldn't classify it as a memory safe language in the same category as Rust, VM languages, and scripting languages. It's more memory safe out of the box than C, sure, but that's not the same thing.

I took your advice on learning c then rust a while ago and it was a great decision, thanks for all the mega cool videos

15:42 why do you describe zig as a memory safe language (or a language that tastes like it's memory safe)? The first zig program I wrote segfaulted because I was careless with pointers. Is zig even in any way safer than C++? Both have tools to help guide you towards safer patterns, but neither compiler actually verifies that you use them correctly. Don't get me wrong, zig is an excellent language and a huge upgrade safetywise over C, but clumping it with memory-safe languages is a stretch

I didn't know Sza was concerned with software safety, makes sense since she wrote ghost in the machine

How does rust work for microcontrollers? Writing to memory has inherent side effects that the compiler can't know about. It feels hard to have memory safe code if the memory goes and changes values when you aren't looking

Miri is valgrind on steroids, it's an amazing tool

I'm not surprised at that number. Heck, I'm surprised it's not higher. Even syscalls are an FFI, so must be considered unsafe. I have a feeling that the Rust devs have "cheated" some with some of the basic syscalls, so that the number isn't closer to 100%.

My bias is leaning towards zig. While still generally memory safe, it feels much more ergonomic than rust. But I can acknowledge that I should do some more bigger projects in rust to get a better idea. I think zig is the perfect bridge from c to the modern world