Rust in the Linux kernel (Google security blog)

Posted Apr 16, 2021 7:06 UTC (Fri) by mkubecek (guest, #130791)
In reply to: Rust in the Linux kernel (Google security blog) by wedsonaf
Parent article: Rust in the Linux kernel (Google security blog)

> If your data can be encapsulated in something that fits in an atomic variable, it is safe and as fast as C. If it can't, then you're still welcome to use atomics and unsafe blocks to implement your lock-free thing.

That's the easy case. But it's not nearly always the case.

> The expectation is that you'll build a safe zero-cost abstraction and restrict the unsafe part to a small section that will be scrutinised, but users of your code will themselves be free of unsafe code.

If it can work like that, it's fine and it likely already works like that even without rust. But it does not nearly always work like that. If it did, you wouldn't find so many occurences of READ_ONCE(), WRITE_ONCE() or explicit memory barriers through the code and we could have them hidden inside those opaque abstractions.

For example, some of the READ_ONCE() and WRITE_ONCE() were added for values set via sysctl or socket options (e.g. various limits or default values) where we don't really care if there is an inconsistency between threads picking the old or new value but as they are used in fast path, we do care about the overhead of having the access really safe. But again, this is just one example which you could probably build some abstraction around; but there are more complicated uses, e.g. just yesterday I stumbled upon the barrier in net_tx_action() and comment explaining why it's needed. And this is still one of the simpler cases. I doubt you can build zero cost abstractions around all of them.

Rust in the Linux kernel (Google security blog)

Posted Apr 16, 2021 7:33 UTC (Fri) by matthias (subscriber, #94967) [Link]

I think READ_ONCE() and WRITE_ONCE() are quite good examples. In a way they already are abstractions. The problem with C is, that there is no easy way of enforcing the usage. With rust, you would wrap data that should be accessed by these macros in a new data type (with zero runtime cost). And the only reason for this type to be there would be to enforce the usage of READ_ONCE() and WRITE_ONCE(). The compiler would just throw an error if you try to access the data by other means (unless you explicitly use unsafe of course).

I do not know the kernel well enough to talk about every feature whether it can be abstracted with zero cost. But it is always possible to use unsafe at the very position where optimization is crucial and document why unsafe is used there and why the code is still safe. Yeah, you would not have a safe abstraction there, but you still would have the unsafe tag expressing that you have to be very careful at this particular place. If you use unsafe, then you can do the very same things that are possible in C.