No resistance to change?

Posted Dec 13, 2025 13:57 UTC (Sat) by patrick_g (subscriber, #44470)
Parent article: The state of the kernel Rust experiment

> the DRM (graphics ) subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.

Wow. That's much quicker than I expected.

to post comments

No resistance to change?

Posted Dec 13, 2025 14:19 UTC (Sat) by pizza (subscriber, #46) [Link]

> Wow. That's much quicker than I expected.

Eh, not really. That kinda was the whole point of this "experiment" [1].

To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.

There is no point in half-measures; those only result in higher costs and fewer benefits.

[1] As the saying goes, "It's only temporary if it doesn't work"

No resistance to change?

Posted Dec 13, 2025 14:41 UTC (Sat) by iabervon (subscriber, #722) [Link] (11 responses)

It's quicker than I had been expecting, but I was thinking of areas where there are a lot of new small similar drivers. DRM has large drivers that cover all of the similar devices up to the point where they've diverged enough to warrant a new design, so it makes sense to be very forward-looking any time you actually start a new one. The resistance to change here is in not asking existing drivers to be rewritten in Rust in order to add new functionality.

No resistance to change?

Posted Dec 14, 2025 3:14 UTC (Sun) by riking (subscriber, #95706) [Link] (10 responses)

GPU drivers are also famously the most crash prone part of modern computers, and it looks like Android is getting good results with their "no new memory unsafe code components" policy. It makes sense to copy.

Filesystem drivers in Rust

Posted Dec 14, 2025 22:23 UTC (Sun) by hailfinger (subscriber, #76962) [Link] (9 responses)

I am looking forward to having more filesystem drivers in Rust. This would solve the "user mounts malicious filesystem" problem to a certain extent (no pun intended). Sure, denial of service would still be possible, but having no code execution bugs in a filesystem driver is a big plus in my book.

Filesystem drivers in Rust

Posted Dec 15, 2025 9:54 UTC (Mon) by taladar (subscriber, #68407) [Link] (4 responses)

Can "denial of service" with a "malicious filesystem" even be considered a problem? I mean wouldn't that essentially always be possible for someone who can craft a malicious filesystem merely by strategically overwriting central filesystem structures?

Filesystem drivers in Rust

Posted Dec 15, 2025 10:23 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

Depends how far the denial of service extends; if it just restricts you from accessing the malicious filesystem, that's not a problem, but if a malicious filesystem can cause the FS driver to hold locks that prevent you accessing any filesystem at all, that's a denial of service attack.

Filesystem drivers in Rust

Posted Dec 15, 2025 12:54 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Depends how far the denial of service extends; if it just restricts you from accessing the malicious filesystem,

...How does one tell the difference between malicious and merely damaged?

(Because a "DoS" preventing accessing the former is arguably good, but arguably bad for the latter..)

Filesystem drivers in Rust

Posted Dec 15, 2025 12:57 UTC (Mon) by farnz (subscriber, #17727) [Link]

If the filesystem is damaged, all bets are off anyway - the damage may extend to the point where the data is irrecoverable. Thus, the contents of the damaged filesystem are already not part of "service" in a security sense, since you've already lost them.

As a quality of implementation matter, being able to retrieve as much data as possible from a damaged filesystem is nice, but it shouldn't affect availability of the system as a whole, only that one filesystem.

Filesystem drivers in Rust

Posted Dec 16, 2025 2:09 UTC (Tue) by corbet (editor, #1) [Link]

Linux has a number of filesystems that can deal properly with a "merely damaged" (corrupted filesystem). A maliciously corrupted filesystem will have correct metadata checksums, and is much harder to detect. There is a qualitative difference.

Filesystem drivers in Rust

Posted Dec 15, 2025 10:38 UTC (Mon) by jengelh (subscriber, #33263) [Link]

look no further than https://lwn.net/Articles/1044432/

Filesystem drivers in Rust

Posted Dec 17, 2025 8:09 UTC (Wed) by koflerdavid (subscriber, #176408) [Link] (2 responses)

Maliciously corrupted file systems are a significant attack vector that the kernel is only insufficiently protected from. There is a reason why mount privileges are part of root.

Writing file systems is already complicated enough without having to worry about it being malicious. And as we have seen from the security hole in a Rust tar library, merely using Rust is not the solution.

Filesystem drivers in Rust

Posted Dec 17, 2025 9:07 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Rust implementations can indeed not protect you from bad, ambiguous standards like those two size fields in the tar one. Nor can it protect you from logic bugs.

That does not mean that it doesn't help you find those by saving you effort on all the other security issues though.

Filesystem drivers in Rust

Posted Dec 17, 2025 10:37 UTC (Wed) by koflerdavid (subscriber, #176408) [Link]

Being safe from malicious file systems comes from conscious design decisions that follow from recognizing file systems as an attack vector. Ambiguity is not magically absent from file systems either, especially if those with multiple implementations. Rust can help with these things of course, but overpromising on that is not a good look.