WUFFS and the Linux kernel [LWN.net]

WUFFS and the Linux kernel

Posted Aug 15, 2024 10:13 UTC (Thu) by farnz (subscriber, #17727)
In reply to: WUFFS by tialaramex
Parent article: Standards for use of unsafe Rust in the kernel

Remembering that WUFFS exists and that other languages of this class (specialised languages suitable only for a particular purpose e.g. crunching big data sets) could be made is much more optimistic and shows us what our future might look like, even though obviously the Linux kernel couldn't be written in WUFFS

Even though you couldn't write the entire Linux kernel in WUFFS, you could design restricted languages for interesting subsets of the Linux kernel. For example, it should be possible to come up with a restricted language for handling on-disk filesystem layout, such that the resulting code will either successfully handle whatever bunch of bytes you give it, or error out nicely because the filesystem is corrupt. It should also be possible to come up with a language that validates all syscall arguments (including following userspace pointers), to protect against weird acts on the part of userspace.

Part of the point of languages like WUFFS is to change the way you develop software that handles potentially dangerous inputs; instead of trying to validate on the fly, you have a layer that maps "all possible inputs" into "either error, or expected input state". And this is valuable because humans are really bad at thinking about "all possible inputs" (there's around 2**44 possible states for my SSD's exposed storage areas, for example, and I doubt that anyone has carefully thought through how xfs will behave for every single one of those 2**44 states supplied to it as "valid XFS image, please mount"). By having the machine say "you haven't come up with an answer for the meaning of these 2**30 states, because they're neither missing a signature, nor valid", you encourage the programmer to think this through fully.

to post comments

WUFFS and the Linux kernel

Posted Aug 31, 2024 15:26 UTC (Sat) by sammythesnake (guest, #17693) [Link] (1 responses)

> there's around 2**44 possible states for my SSD's exposed storage areas

You have a 44 bit SSD? [scratches head]

Did you perhaps mean something like 2**2**44 (which by my quick stab at calculating corresponds to a ~2TB drive)

WUFFS and the Linux kernel

Posted Aug 31, 2024 17:18 UTC (Sat) by farnz (subscriber, #17727) [Link]

I did indeed mean 2**(2**44), since I have a 2 TiB exposed capacity drive (no idea how much raw capacity there is) - it's a huge number of possible states. And if I understated the number, that just makes it worse - the underlying issue that WUFFS and friends aim to help you with is reducing the number of input states from "all possible bit patterns" to "valid bit patterns", by forcing you to provide functions from "possible bit pattern" to "valid bit pattern or error state".

WUFFS and the Linux kernel

Posted Aug 31, 2024 17:30 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> Part of the point of languages like WUFFS is to change the way you develop software that handles potentially dangerous inputs; instead of trying to validate on the fly,

For filesystems, you still have to validate on the fly. Because there are constructs that are valid in isolation but conflict with each other. You have to validate (and maintain) the _entire_ state holistically, and that is not practical when your metadata alone can easily exceed your memory size.

Valid structures and bugs

Posted Sep 1, 2024 9:26 UTC (Sun) by farnz (subscriber, #17727) [Link]

That's part of what I mean by "change the way you think"; if you've designed your filesystem such that constructs that are valid in isolation result in kernel bugs when combined, you have a problem. If you merely have a situation where the kernel remains bug-free, but there's data loss on a corrupt filesystem due to the conflicting structures (e.g. two inodes sharing an extent record means that either inode can modify that extent record), then you don't have a problem.

And part of this is distinguishing severities of bug; a filesystem bug that gives me total control of your machine because a consequence of an impossible construct being present is that the kernel jumps to an attacker-controller address is a different type of bug to one where the filesystem, when faced with a corrupted filesystem image, corrupts it further.