I would not really have noticed if there wasn't this section about why rust, where arguments looks phony and clearly made up afterward to justify a decision that was already taken:
This project was written in rust, because memory safety is critical in a panic handler.
For this particular case, I found the Rust code to be cleaner, and easier to read.(I would agree the first argument is kinda wavy. If anything the panic handler has a fairly unique relationship with memory safety: it's likely to be executing in an environment where that's already gone out the window and it needs to try to assume as little as possible about what might or might not be correct that its reading from and writing to, while also its own memory safety is perhaps less critical because the system is already crashing, it's just got to get the info out before everything completely stops. Though that doesn't make it immune from security concerns. A code execution vulnerability in the handler means any panic could turn into a worse problem)
Rust vs C matters a lot more for maintainers, who read the source code - hopefully not from a machine which is currently crashing - than for the executable kernel itself.
> There is no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel.
Which I think is fairer. Good on him for trying to stay on top of recent developments. With Linux basically supporting Rust now so it's a valid choice, especially for a new component. Plus, it's not like this is an important features, the anti-Rust people can live perfectly fine without QR code crash dumps like they have for decades now.
I think doing this in C is an unnecessary risk (you really don't need all that many raw pointer interactions and shared struct ownership) but the security and stability of this component hardly matters. The kernel is already dead because of a bug or a hardware failure anyway, this is just making the catastrophic failure of the rest of the system a bit prettier.
"Pronouns: He/Him" https://gitlab.com/kdj0c
My apologies to kdj0c if he's reading this.
Good catch the earlier comment, with that I would not even have raise an eyebrow because it is more a motivation that I find valid and not fishy like the post rationalization that is in the original post.
That being said, I still find it ridicule the attempt to emphasis on how dangerous it is to do "C code" for the kernel because not memory safe all of that, when you see for how long the kernel exist, was able thrive, with relatively few critical issues in the end compared to most software out there.
As in: I can't be bothered to write memory safe code.
This project is a great example of where and when Rust should be used.
"sneak" some rust in the kernel? It is exactly this kind of attitude that is slowing progress.
It has nothing to do with digital rights management.
Its not like in windows where you get some cryptic error code. This is just encoding kernel panic traces as a QR code, so more can fit on the screen without scrolling and copying is easy.
It's always easier to read and share text, e.g. over the phone, and not have to rely on another complex layer of obscurity --- especially when you're trying to figure out what happened.
Of course, it doesn't mean that the QR code could also not be cut off the screen, but since QR code is more dense in information (like the post says), I think this is more rare.
You take a picture on your phone and either decode the QR code on your phone
Not everyone has nor wants another corporate surveillance device.
Funny story: on an x86 motherboard with no serial, I recently resorted to using an old 4K monitor with the 4x6 tiny console font to catch a panic (that netconsole wouldn't log for some reason).
I probably won't be enabling this on my machines, but good on them for trying to improve on the Linux panic screen.
danhor•7mo ago
homebrewer•7mo ago
kokada•7mo ago
sudobash1•7mo ago
grep CONFIG_DRM_PANIC_SCREEN_QR_CODE /boot/config-$(uname -r)
(Fedora is enabling the DRM panic screen QR code)