Rust Programming Language Other Meetups, 10 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Rust NYC: Jon Gjengset - Demystifying unsafe code

Description

Unsafe code is something we, as Rust programmers, have a complicated relationship with. Some shrug it off as "it's fine, it's just C", while others declare any use of unsafe as irresponsible and a strike against any code that uses it. Many of us sit somewhere in between, often because we are unsure what this unsafe thing even really is. Is it truly as disastrous as some say, or is it really just harmless and overblown as others claim? In this talk, we explore the pages of the nomicon and take a look at what unsafe really means, why it is dangerous, why it is sometimes useful nonetheless, and how to deal with it responsibly.

Thanks to our sponsors for the Rust NYC meetup and especially timber.io for sponsoring the film crew.

Slides: https://jon.thesquareplanet.com/slides/demystifying-unsafe/
Slides PDF: https://jon.thesquareplanet.com/slides/demystifying-unsafe/export.pdf
Meetup: https://www.meetup.com/Rust-NYC/
Jon: https://twitter.com/jonhoo

A

So my name is John for those of you who don't already know me from one medium or another, so one thing I keep observing about the Ross community is how we're all like allergic to unsafe code, or we think that unsafe code is is totally fine and not nothing to worry about, um and I wanted to take a little bit of time to talk about what unsafe is because I think a lot of where the communities lack of alignment on this particular topic comes from a fact that unsafe is a bit of a mystery to many of us and I.

A

Think I want to solve that problem, I'm not of the illusion that I can solve this problem in like 25 minutes, but I will try. So in this talk, I'm gonna try to demystify unsafe I'm, not going to teach you how to write correct, unsafe code, but I am gonna. Try to explain some of the reasons why you might actually want unsafe and some of the reasons why you should be careful about unsafe and it's not something you should use just sort of willy-nilly.

A

You can also sum up the this talk, basically as it's just--see versus at certain doom. Neither of these extremes are correct and it's very important that we all agree on this. Like writing. Unsafe is not just writing C code. It is more dangerous than that and I'll explain how, but it is also not certain doom. There are a lot of things that unsafe is necessary for or useful for, and we need to acknowledge that as well and so I want to go through first.

A

Why we need unsafe, like what do we have unsafe in the language in the first place, my address is supposed to be a safe language. Why unsafe, and it turns out there are a bunch of reasons why you need unsafe in particular. Unsafe is there to ensure that we can write code whose safety relies on get invariants, that the compiler cannot check for us and I'll go through some of them.

A

Is these examples as we go through these slides, but the idea is that in unsafe code we are the borrow checker, because the borrowed checker cannot check whatever it is that we are doing and not just borrow checker but more about the sort of safety guarantees and requirements. The trust has. The first example of this is working with hardware devices.

A

So when you work with hardware devices- and let's say you want to show some screening the screen when your computer boots at this time like there is no operating system, all you have are just like raw pointers that are specified in like the Intel manual or the BIOS manual or the manual of some obscure thing from the 80s, and so you happen to know by magic that, at this address in memory, there's a chunk of bytes that you can write to and then text appears on-screen. It's true.

A

This is where you can write stuff to write things on screen during boot. The compiler has no way of knowing this. This is something you know as the programmer, and you know that no one else is writing to that address right now, because it you're in boot mode like there is nothing else. There are no threads, and so you know a bunch of things that the compiler does not. So you can write this code right. You can cast this pointer to a mutable pointer and then turn it into a mutable slice.

A

You know that this code is safe at this moment in time. The compiler has no way of knowing writing this code.

B

Anywhere else like.

A

In your regular, like FN main, would not be safe, but it is safe during boot. On hardware, where you know this pointer is mapped. This is the kind of stuff we're dealing with or unsafe as necessary, because the compiler has no hope of checking this code. Another example is when you want to interact with external code right. Imagine you want to call into a C library, or maybe the C library is really like Java through J&I, or something like that. The compiler has no idea what that code does for all. It knows like it's.

A

Just gonna write zeros to all of the memory right. It has no clue. You are asserting that you know that the code that this ultimately calls doesn't do something stupid, you're, asserting that that code upholds all of rusts safety guarantees. The compiler can't check it for you. It has no way to do that, and so you need to use unsafe to tell the compiler that you have checked another place where unsafe comes up. A lot is when writing concurrency, primitives, right and I. Imagine that you want to implement the mutex type.

A

What does the mutex type do? Well internally, it holds a like just a straight-up pointer to some place in memory that sometimes it gives out immutable reference to. The compiler has no way to know that we are carefully checking all of the invariants to ensure that we only ever give out a mutable reference to that pointer to one thread at a time right.

B

Like this is the API for mutex.

A

Right when you locked it's gonna, do some kind of atomic. This is not how all mutex is are implemented, but this is one example where you're gonna just like compare and swap a value until it becomes true, and at that point you know that no one else is in this segment of code. No one.

B

Else has a mutex guard.

A

And so it it is okay for you to implement D, ref mute for that guard and give out the mutable pointer. But the compiler can't know this. The compiler doesn't know that no one else is swapping this back to false right, and so we need unsafe to tell the compiler that we have carefully read our code, and we know that is the case. um There.

B

A

Another category that I'm hesitant to even race but I, think it's important one. When we talk about unsafe and that is overcoming borrow checker limitations, there are some patterns that the rustboro checker is not quite smart enough to figure out yet, usually these are already known issues and you can look them up, unlike the rust issue tracker one example of this is if you want to return a reference early by downgrading a mutable reference, so this function right here.

A

If you have the sequence of functions, this will not compile currently on the rest compiler under the current borrow checker, it's a known bug, and it's something that you have no way of writing this code correctly, that the borrow checker will accept, and so you can fix this with unsafe. You probably shouldn't like find a different way to write your code.

A

That is probably better, and this is also why I'm not showing you the code to work around the borrow checker here, because you probably shouldn't do it generally, if the borrow checker tells you that your code is not safe, it's right and if you get into the habit of like forcing it to just like now, I know what I'm doing you're, probably wrong. Some of the time and I can have really bad consequences, as we'll see later, usually with the borrow checker, it's better to either write your code slightly differently or just wait a bit.

A

The bar checker is improving day by day. We also have Polonius this new sort of Baro checker iteration. That's coming down the line which will fix many of these problems. The last category that comes up a lot is performance optimizations, and this is maybe the most contentious way to use unsafe, where there is a safe way to write your code, but you chose to write it in an unsafe way, because you wanted, like the very last ounce of performance out of your code, and sometimes that really is necessary, but I urge you to measure.

A

First, and preferably twice, it is very rarely worth that marginal performance increase that you usually get at the cost of what adding unsafe to your code introduces because now, suddenly, you are telling the compiler that you have checked some invariant that you need to make sure holds for all eternity going forward in your code.

A

It is much easier to just not have that responsibility if you do measure and you find that it's necessary then do it unsafe is there for that, but be very careful now that I mentioned some of the reasons why you might need unsafe I also want to talk about the ways in which unsafe can go wrong, because this is where the sort of other extreme of the crowd often lends is that we need unsafe for a bunch of things, so we're just gonna use it.

A

What's the worst that could happen like you, dereference a pointer, you get a segfault through. That's not that bad right and it turns out. That's not all that can happen. Bad unsafe is a real problem. Remember that with unsafe we're telling the compiler that the code is okay, we are telling it that we checked it manually very rigorously that everything is right. We checked the code, never violates any part of rust safety guarantees that the rust type systems guarantees are all completely in place. We're asserting that the unsafe code is safe.

A

Unsafe is not a way to avoid the rules of rust. It is an escape hatch that lets you write code with fewer restrictions, but you still need to uphold all of the rust safety guarantees and it all comes down to our you sure that you're upholding all of us guarantees. Do you even know what all of them are? If the answer is no, then you should learn what they are or you should not be writing unsafe code, because some of them are pretty subtle.

A

In particular, the compiler assumes that all code, whether safe or unsafe, always follows all of these rules and a couple of more it assumes that no code ever dereferences a dangling or unaligned pointer. It assumes that no code ever violates the pointer aliasing rules. I should say reference. Aliasing rules. Sorry, it assumes that no code ever causes any unsynchronized data race with the right.

A

It assumes that no code ever produces invalid value and there are all sorts of invalid values and there's a lot of debate, even when the people who really know unsafe as to what a valid value even is in rust, is any bit pattern. A valid f/64. It's not clear. Maybe this is one of the things that they're trying to figure out is any bit pattern for a boolean byte knowledge is not clear.

A

I think the respect currently says it has to be zero or one trying to take any other bit pattern and casting it to a boolean is undefined behavior, and you need to be aware of all of these rules. If you are to write correct, unsafe code, some of them may not apply and in some cases the ways in which bad unsafe code relate to these might be hard to discern, but it's worthwhile to keep them in mind that these rules always apply to you. So what are the effects like if you break one of these?

A

What happens? Well, usually, incorrect use of unsafe is undefined behavior. Not always there are some cases where it's not, but usually that is the case. An undefined behavior is like playing Russian roulette.

A

Okay, I cannot say this strongly enough that when you use unsafe code incorrectly and you end up with undefined behavior, you have no guarantees what your program is going to do and the effect ranges from none to your program, site faulting, to arbitrary data, corruption in memory and think about what that means. That could mean, like your code, takes an entirely different path. Through your program, the wrong data gets stored in your database. The access check gets flipped from a false to a true.

A

You have no idea worse than that when you have undefined behavior, the effects may not appear today, but then suddenly appear tomorrow. Eve even for no reason like it might depend on your hardware or the hardware. The persons running it on it might depend on the exact compiler version. It might depend on the face of the moon. You do not know, and that is why you need to be so careful with undefined behavior, because it's very hard to predict where it's gonna go.

A

You basically have no guarantees and in all code you write you should avoid undefined behavior like it is just never okay. So so, let's look at some examples of things that can go wrong. So there's some code on the slides here I want you to look on the left side. First, so, on the left side, I have a function compute and it takes an immutable reference to a number and a mutable reference to a number, and if that number is greater than 10, then it sets the second number to be 1.

A

If the input number is greater than 5, then it doubles. The second number in rust the compiler, is allowed to assume that the code on the right is the same as the code on the left. That is, it's allowed to assume that it can just read the left value once and just sort of cache it, and that can optimize away the double check for the. If and specifically in C and C++. This optimization would not be legal because I and O the two parameters to the function could point to the same memory in C.

A

That is totally the case and if they point to the same memory, then imagine what happens. We take this branch, but then we don't take this branch that is possible in C. That is not possible in rust, and so, if you break the aliasing rules as an example right, imagine that you have some value and you give out a mutable reference and an immutable reference to it. Someone could call a function like this. The compiler optimizes it into this under the assumptions of the aliasing rules. So it runs it this way.

A

So your code now suddenly produces the wrong answer, because you were violating the aliasing rules which the compiler relied on another example. This is a bit more code, but I want to walk through it because it's a little bit subtle. So here we're gonna write a function on that that is going to be extended map and the idea is, it's gonna, take a slice of use and it's going to take a function, that maps use to T's and there's gonna extend the vector with the mapping of each utility right.

A

It's a relatively straightforward function in terms of what it does and we are smart developers. We don't want to do many pushes in a row because then we might have to grow the vector multiple times and that's a waste. So what we're gonna do is we're first gonna reserve enough space in the vector for all of the elements we're about to push and then we're gonna get the current length and then we're gonna unsafely, set the length of the vector and keep a pointer to the beginning of it, and then we're gonna loop over all.

A

The inputs call f on each one and do just a point two right into the next element in the vector. Now this code is correct, like there's no bug in this code, however. Well sorry there's no bug in the the business logic of this code. If you run it and everything goes normally, then this works used correctly and does the right thing. So you don't need to look for that.

A

But I want you to ask you a question: what happens if f, here panics, if f panics, then this function is going to return and its parent is gonna panic and there's gonna bubble up and eventually this vector is going to be dropped when this vector is dropped? What if the vector do it walks all of it, ello its elements and calls drop on them, but we set the length here and we panic before we wrote out all of the elements.

A

This means that some of the elements in the vector, so some of the things that are between the start of the vector and the end of the vector, contained uninitialized memory right we haven't written those values yet and so dropping them is just gonna call some arbitrary garbage memory, and this is undefined behavior. It turns out that this is one of the reasons why writing a correct drain?

A

Implementations for data structures is really hard because you need to deal with this problem of what, if someone panics after they call drain or what, if someone just doesn't call next all the way, and you need to think about all of these cases- here's another one that I actually ran into relatively recently with a similar data structure.

A

So here we're gonna have something called a lazy drop thing, and the idea is that we want to be performant, and so therefore, instead of just dropping every element when we drop a vector, we're just gonna like push it to some global queue and then we're gonna drop them all later at some unspecified time in the future, because dropping them in batches probably more efficient than dropping the worn by one right. So when it's dropped, we're gonna, walk all the elements of this vector and we're just gonna drop later into some like global collector.

A

It's not important what it is, so this code is wrong and the reason it is wrong is if this T is some type that is not static. That type contains a reference of some kind. Imagine it contains a mutable reference to TCP stream and when that type is dropped, it's gonna write it to that TCP stream. Well, that mutable reference is no longer valid by the time this collector decides to drop things, and so here's an example of the bug is in the safe code. The bug is that T needs to require static here.

A

Otherwise this is not okay. When you have unsafe, the unsafe T is not just about the code contained in the unsafe block. It's about the entire public visibility boundary of that code. You need to audit the safe and unsafe code in any module that contains unsafe.

A

Here's another example that many of you might have heard of already. So this is the offset of macro I've taken it from the memo offset crate it's a little bit more complicated in the crate, but it's basically this code. Okay. So here we construct some uninitialized memory and we use the maybe on it type, because we know that that's important to tell the compiler we're not going to use this memory because it's not initialized. Yet we get a pointer to the start of the memory.

A

We here get a reference to the given field of that initialize memory and just cast it to a pointer right, and here we're not even dereferencing the pointer, really we're just taking an address right and then we compute the offset of the given field inside of that type as the difference between the two pointers.

A

The problem here is imagine that this type is reprobate. So if it's Reppert act, what that means is there's no space between the different fields, there's no padding in the struct. This means that types are not guaranteed to be aligned to their own size. So if you have a use 64 normally in a struct and rust, then it will be aligned to a 64 bit boundary there'll be 8 byte aligned.

A

Similarly, a boolean will be byte aligned, you 16 will be 2, bytes, aligned, etc and rust requires that every pointer, sorry, every reference is aligned. It must refer to an aligned location for the type, the references for right here. We are constructing a reference to a field, we're not D referencing it right we're not reading or writing this memory, we're not using the pointer, we're just constructing a reference and then immediately casting it to a pointer.

A

This is undefined behavior because you are constructing a reference that is not aligned or might not be aligned, and so, if someone tried to call this with a type and a field and a packed struct, then they would be invoking undefined behavior in what appears to them is safe code.

A

What the compiler does with it, it's hard to say who knows right, but it's important to know that these things can be broken in this way, and so, when it comes to the integrity of unsafe code, you have to remember that safe interfaces to unsafe code, they have to behave correctly, no matter what the safe code does. When you write unsafe code, you can't rely on the safe code being correct. You can rely on the on the safe code being safe.

A

You can rely on it, not corrupting memory but like if someone has like an eat that returns randomly true or false, or that, like their order, is random or there's like a weird implementation of D ref, the like dearest, an arbitrary element of a vector or something like you're unsafe code needs to not have undefined behavior. Even in those cases. This is one thing that the standard library worked.

A

A lot with when it came to B tree maps is that the implementation of B tree map has a bunch of unsafe code, but they can't rely on the ordering of the type being correct they can crash like crashing is fine. It's just you can't accidentally invoke undefined behavior and that took a lot of thinking for a complex data structure when it comes to sort of internal unsafe code.

A

This is something that comes up a lot, especially when we look at other people's projects is that they have unsafe code inside of their library, and they go this one. Save it code is fine, even though I have a maybe audited it that much because no one can get to it. No one can use it; no one can call it externally and therefore it is fine, and that is not true.

A

First of all, safe code in the same module is unsafe code, as we saw can have an effect on the safety of the unsafe code, and part of the reason for this is that in safe code in the same module you can access things like private fields and the unsafe code might rely on the integrity of those fields, but it has no way to say so, and so the safe code might accidentally change that code.

A

This is why encapsulation of unsafe has to happen at the visibility boundary, which is usually the module boundary, but think of it as it has to happen at the boundary where things are pub and keep in mind that you don't generally want to assume that callers of your code are gonna. Remember all the safety invariants. If you have some type that internally uses on say, but you make the function safe so that you don't have to put unsafe everywhere, then that's all good and well. But what?

A

If, like four years later, you're modifying some code and you're calling that safe function- and you forgot that you can't do that if you also called some other function somewhere else, but it's not marked as unsafe, so you don't think twice about it. This is why, even in your own code, try to make sure that anything that is unsafe is marked as such. Now going through this.

A

You might think that, like all hope, is lost right, like all these reasons, why we need unsafe, but it's really hard to get unsafe code right, so we should just give up and go home and go back to UC or Java, or something like that and I would argue. That's not the case. It is totally possible to write correct, unsafe code, there's a very simple checklist.

A

First of all, be sure that you need unsafe code and second be, like really sure and third read the nomicon, so the nomicon is sort of like the rust book, but for unsafe it documents a lot of what I've talked about here and a lot more that you need to know in order to write, correct, unsafe code. Make sure to read it like preferably start to finish and then just be very careful whenever you're writing unsafe code.

A

Keep this fact in mind whenever you write the unsafe key word, you need to think about the implications of that and look at the other code in that same module. You also, then, want to make sure that you document all of your unsafe blocks. It does not just unsafe functions and such but any unsafe block as well put a little comment above it with like safety, : and then explain why that call is safe.

A

It's gonna save you a lot of trouble later on when, four years later, you need to figure out why this code is safe or if you get some contributor to your project, who has to figure out whether this is actually safe, because someone reported a button and then I recommend that you set up CI for your project to run Miri and the address sanitizer. These are both relatively straightforward to set up for us projects, I highly recommend both of them I, want to take a brief aside when it comes to Miri.

A

Cuz Miri is a fantastic tool, um so Miri is a interpreter for rusts Mir like the mid-level interpreted language or representation, I guess the rust and basically it lets. You run rust code in the compiler it lets you interpret rust code while you're in the context of the compiler, and it does so essentially by emulating all of memory at compile time, and this means that it can check that your code doesn't do anything bad.

A

It can run your code run a test or something like that and make sure that every like every reference that is constructed is aligned and all of these other things we've talked about and it even works on the playground like on the rest playground. You can click a little button and then run miri, and it will helpfully do things to your code. So, for example, for the broken extend map we had earlier. I tried this code on the playground, so I created an empty vector and then I tried to extend it with the map closure.

A

Just panicking. I ran it through Miri and Miri says not. Okay type validation failed. It encountered under this choice bite, but it expected something that was not uninitialized basically, and if you look back at the trace, you'll see that it ultimately ends up at vector op.

A

This is extremely useful if you're writing on safe code to get this kind of information of yes, you're unsafe code is not correct. Here's how to fix it so with that I hope that you've, like understood a little bit more now about why we need unsafe and the ways in which unsafe is dangerous and what you can do in order to try to mitigate the risks of that and safety in your code, room forward, Thanks and that's all I have.

A

A

How does repper work at all so for for repartee mean specifically yes yeah, so for repre it used to be that the compiler would just let you take references to fields. It is now after they realized that this was not okay, if you have a rapper pack type and you try to take a reference to a field that happens to not be aligned, you'll get a compiler warning, and that is going to become a hard error, probably in the next edition. As far as to how you use them.

A

This is one of the reasons why it's tricky to use pack structs in rust at the moment. This is also one of the reasons why we have the an RFC that recently came up on Raw pointers on being able to take a raw reference, which is a reference that does not have the alignment requirement. Basically, yep.

A

Incorrect unsafe code that does not lead to undefined behavior.

A

Not of the top of my head I mean. Obviously you can write unsafe code that just like, like adds.

B

Two numbers incorrectly right like it's incorrect, but.

A

It's not a great because it's unsafe I can't.

B

Immediately. Think of one but.

A

The the two categories are not entirely overlapping I, just can't think of one of the doc man.

A

A data race between a right and a read that is not synchronized is undefined. Behavior.

B

The house was basically publishing public papers about time to prove.

A

B

Trades are lawful type class instances and waffle and they the laws, were ordered to that an implementation or a library event use. If you have a verified origin, seven or you can make that assumption in the data terms. Reminder is anybody working on some kind of formal method strategy like that for Ross I know the Rust Belt project ultimately wants to help verify unsafe.

B

A

I'm, gonna repeat your question just for the for the recording, so the question is there have been a bunch of efforts on gear or on proving that certain traits are lawful in the sense that they follow their contract. This is things like or danique that they actually do something sensible and correct, and the question is: if you have something like that. Well, the first.

B

Question is, if you have something.

A

Like that, can you take advantage of that in your implementation, and the second of that is: is there such an effort for rust yeah, so whether you can take advantage of that? Probably my guess is certainly in the beat remap code I'm sure there are cases where they have to do something a little janky, because just in case the user did not use Ord correctly I, don't know of any particular optimizations you can make, but it might be able to remove some like extra safety checking code, I'm, not sure.

A

As for efforts in rust to do this, I don't know of any that there might be, but my.

B

Guess is also that, with.

A

Something like rust belt rust. You would sort of get this because, once you prove the correctness of code, according to some specification, then like you already have pretty strong guarantees, although that's more about safety, so what what they could do, then is they could show that if the Ord implementation was not saying that the code still does not exhibit any undefined behavior.

A

Great. Thank you. Everyone.