Rust in QEMU Roadmap

Is this a troll? Isn’t Adobe Reader one of the easiest pieces of software to exploit because it enables risky features by default and lacks proper sandboxing? Just searching for “adobe reader security vulnerability” brings up a critical software update for CVE-2023-26369 as a top hit which is:

> Acrobat Reader versions 23.003.20284 (and earlier), 20.005.30516 (and earlier) and 20.005.30514 (and earlier) are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

> The claim, often cited from a Google study, that memory corruption bugs pose the largest risk feels exaggerated in this context

Actually this comes from analysis of NIST data which tries to track vulnerabilities and memory safety resulting in arbitrary code execution consistently shows up as the number one issue for C/C++ despite it being a non issue for most other languages. Indeed here’s the vulnerabilities for adobe reader and they’re dominated by memory safety issues: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Adobe+reade...

> Don't even get me started on Rust syntax... I am convinced the syntax was intentionally developed to troll us all with the ugliest syntax on the planer.. I'll stop now before I begin ranting forever.

Rust shows what it takes from a language to achieve compile time memory safety (and the same syntax also provides thread safety) with the performance profile of C/C++. The syntax actually isn’t that hard to get used to and learn and I’d argue it’s easier for beginners since incorrect code will throw an error and explain what’s going wrong instead of crashing at compile time. In the static vs dynamic verification spectrum it costs more static verification. Indeed, from that perspective, why are you even coding in c++? Use assembly if it’s too high level and you don’t like syntax getting in your way or use Javascript so that you can write code that has almost no static checking. In practice rust is waaaaay nicer to write in with a much more mature and reliable project build system that works the same everywhere with a rich ecosystem of tooling that is trivially accessible. The standard library is high performance with a lot of things available that c++ would only dream of with c++ still arguing how to make breaking changes to the language in the standard body, a problem that rust developers don’t even think about (eg rust hashmaps are faster and higher quality than c++ maps).

It's a common thing to do in projects like this in C. While C++ solves some of the problems for larger projects, it brings so many more, it's usually not worth it. Projects of this kind, essentially, invent their own language, with their own conventions. C is just a convenient tool (given the alternatives...) to do that, as it's treated as a kind of a transpilation target. Think about languages like Haskell which essentially work like that, but went even further.

So, what typically happens is that memory allocation, I/O and concurrency need to be done differently from how the language runtime wants to do that. So, at this point, you basically throw away most of the existing language runtime. From my recent encounters with different bugs in QEMU, I imagine that they really, really need a lot of customization in how memory is allocated (my particular case was that QEMU was segfaulting when running ldconfig in aarch64 emulation, which turned out to be due to ldconfig having some weird custom-made memory allocation pattern which QEMU cannot account for.) It's easier to fight this battle with C than it is with C++.

However there is a reason to have the object model, and it was added because some things were getting out of hand. You had to write three parsers for everything you added: one for command line, one for the text-based command interface and one for the JSON API. And you had to do it once for each kind of "object" (device, network backend, disk backend, character device backend etc.). The object model is designed to let you write code just once for all three and to reuse the interface across object types.

Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well.

I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In my opinion I also just don't see younger people and newcomers putting up with that when there's a shiny new alternative. And if you want to sustain you have to attract new people and potential maintainers.

Other than that, I agree that the rewriting is mostly not warranted. The thing is, it is about people and not really about code or programming language. If your entire team knows C well and will be able to maintain that project for years to come, it'd be weird to rewrite it all.