Rust heads into the kernel?

Posted Apr 21, 2021 18:25 UTC (Wed) by ibukanov (subscriber, #3942)
Parent article: Rust heads into the kernel?

Wuffs [1] is more appropriate for the kernel. It is much safer than Rust. For example, compiler ensures that there is no integer overflow or out-of-bounds array access. This is in addition to ensuring that pointer manipulations are safe. Plus it compiles to plain C so there is no issue with unsupported architecture.

[1] https://github.com/google/wuffs

Rust heads into the kernel?

Posted Apr 21, 2021 18:59 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

I dare say it would be, if it was production-ready.

When the latest version tag in the git tree is v0.3.0-beta.1, I feel it's safe to presume that the people responsible for developing it don't think it's production-ready.

Rust heads into the kernel?

Posted Apr 21, 2021 23:07 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

I don't think so.

> Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety.

> The idea isn't to write your whole program in Wuffs, only the parts that are both performance-conscious and security-conscious.

A lot of driver code is boring. That code needs to be easy to write. In Rust it can be easy, in Wuffs not so easy.

Rust heads into the kernel?

Posted Apr 21, 2021 23:09 UTC (Wed) by roc (subscriber, #30627) [Link]

Also

> No way to dynamically allocate or free memory.

Rust heads into the kernel?

Posted Apr 22, 2021 11:00 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (1 responses)

Still with Rust one gets panics on out-of-band access plus there is no check for overflow in release builds. Which suggest that maybe for drivers the whole code should be sandboxed using Wasm or similar. Then one can continue to write borring code in C or Rust with all bugs contained.

Rust heads into the kernel?

Posted Apr 22, 2021 16:31 UTC (Thu) by zlynx (guest, #2285) [Link]

The overflow and other debug checks can be enabled in Rust release builds if you want it.

As I understand it the Rust panic will be wired into a kernel BUG call. Which is what it ought to be. If the code somehow avoids the explicit range checks and still executes an array[out_of_bounds] operation then that really is a BUG, unlike a memory allocation failure.

Wuffs

Posted Apr 23, 2021 3:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Wuffs will cheerfully provide you with C, and presumably in the future if you wanted it could be altered to provide Rust although in most cases I can't see why you'd care since if you're just compiling it then C is easier, and if you _alter_ the code then the guarantees from Wuffs expire.

But Wuffs is a special purpose language whereas Rust isn't. For example when you ask Cargo for a new Rust program, the one you get says "Hello, World!". But Wuffs can't do that. Because that would involve I/O and Wuffs deliberately doesn't have I/O at all, it considers that to be orthogonal to its concerns entirely.

It is good for these special purpose languages to exist, particularly when they address some difficult and interesting problem such as "Wrangling Untrusted File Formats Safely". I should like to do this sometimes, and apparently Wuffs would help. But if my current problem is that my USB Foozle doesn't work, an "untrusted file format" is only at best a tiny fraction of my problem and Wuffs isn't interested in helping me with the rest of it. Whereas perhaps I can write a driver for the USB Foozle in Rust.

Today I can write a _userspace_ USB driver in Rust. Maybe my Foozle can be driven that way. If Linux Rust becomes a thing then that opens up the possibility of writing a kernel USB driver in Rust which is viable even for higher performance gizmos and is also desirable if a Foozle is important/ low-level enough that people don't really want to wait until the userspace spins up to have it working.