5 ms·

Telling QEMU to move from C to Rust is bad idea imo. QEMU Devs are probably well versed in Source code of QEMU and C. Telling them to learn new language and rew

Telling QEMU to move from C to Rust is bad idea imo. QEMU Devs are probably well versed in Source code of QEMU and C. Telling them to learn new language and rewrite QEMU would be a joke. It would give lot of new problems than solving the current issues. Probably, RUST Devs who are well versed in emulation can start another project in RUST which has same goals of QEMU but telling existing software to rewrite is a big JOKE to be laughed at. This has nothing to do with RUST but "Rewrite in New language" syndrome.

jdub 6y ago
A major QEMU contributor suggesting that future work on a specific subset of components (that are prone to vulnerabilities that are difficult to avoid in C) be done in Rust is not naïve. It's the beginning of a community discussion.
Twirrim 6y ago
First up, the person writing the blog post is actively involved in QEMU development. It's not some random person evangelising use of Rust. It's most definitely not naive for them to suggest such a thing, but instead exactly how such things ought to be done. Secondly, you may be started to find out that the QEMU developers seem to be in agreement, with the interest related to Rust for vhost-user, and considering ways interfaces etc. might make that feasible. OPs post to the QEMU development list, thread makes for interesting reading: https://lore.kernel.org/qemu-devel/CAJSP0QWF8g7r5VqU_PRbskWZU3ahCq+eobR8GexUcPrAiYoCPQ@mail.gmail.com/ https://lore.kernel.org/qemu-devel/CAJSP0QWF8g7r5VqU_PRbskWZ...
xemdetia 6y ago
Yeah, there's no discussion on this blog post of what a lot of people are doing in writing project-specific linters, static analysis passes, code generators and so on that just ensure higher code quality which to me is more bleeding edge when it comes to actually helping. There's also no mention of the fact QEMU is tightly bound to other C based projects like libvirt and KVM and having developers be able to switch back and forth is extraordinarily useful. It wouldn't just be replacing QEMU but also the ecosystem around QEMU. It's not like QEMU is the application at the end of a dependency chain, it's in the middle for a lot of users.
Ar-Curunir 6y ago
And maybe you should read the conclusion of the article before commenting on it?
pquerna 6y ago
Hello. I'm not a QEMU developer. I used to be pretty active in Apache HTTPD, APR and related projects. They are large user space code bases written in C - with, overall, a relatively OK security record. I think Apache should be on a path to be rewritten in Rust. Here's why... Every new line of C has a chance of a remotely exploitable vulnerability. No matter the precautions taken, no matter the developer who writes it. HTTPD has a long history, precautions like memory pools from APR and uses "safe" string functions, but it still has issues. Apache's core C code doesn't change much, so yes, many remotely exploitable memory corruption bugs have been fixed over 20+ years, but new code, new code still has bugs. And they can be bad. Look at the recent known vulnerabilities in httpd: https://httpd.apache.org/security/vulnerabilities_24.html https://httpd.apache.org/security/vulnerabilities_24.html Vulns that are largely fixed by Rust are concentrated areas like HTTP/2 support and the Proxy - areas under active development. Vulns around logical errors are still there, and more widespread, but largely have a lower impact. So, I emphasize with QEMU developers. I'm in the same boat. I have a full time job, and that job is not to work on Apache HTTPD. It would take a full time job to incrementally adopt Rust. The outcome would be in 24+ months, no more remote memory corruption bugs. Is it worth it to fund this? Can you put a price tag on this for the dozens of "core infrastructure" software projects written in C?
- secondcoming 6y ago
  No offense, but rewriting httpd in rust won't make it any better. There's no excuse for thread-per-connection in 2020.
  - AgentME 6y ago
    That's not at all the issue they said that Rust would help with.
    - secondcoming 6y ago
      Yes but porting httpd to another language would just be putting lipstick on a pig!
  - 6y ago
mmis1000 6y ago
> This raises the bar to learning the language, but I look at it this way: learning Rust is humanly possible, writing bug-free C code is not. It's simply impossible to write completely safe c code. Lots of bug like heart bleed, dirty cow, whatever, you name it was write by people that have dozens years of experiment and they still make accidents. Switch the language is expensive of course. But it might worth it eventually if this project continue to run for a long time (or the project got abandoned before it pays off, who knows?)

jdub 6y ago

A major QEMU contributor suggesting that future work on a specific subset of components (that are prone to vulnerabilities that are difficult to avoid in C) be done in Rust is not naïve. It's the beginning of a community discussion.

Twirrim 6y ago

First up, the person writing the blog post is actively involved in QEMU development. It's not some random person evangelising use of Rust. It's most definitely not naive for them to suggest such a thing, but instead exactly how such things ought to be done. Secondly, you may be started to find out that the QEMU developers seem to be in agreement, with the interest related to Rust for vhost-user, and considering ways interfaces etc. might make that feasible. OPs post to the QEMU development list, thread makes for interesting reading: https://lore.kernel.org/qemu-devel/CAJSP0QWF8g7r5VqU_PRbskWZU3ahCq+eobR8GexUcPrAiYoCPQ@mail.gmail.com/ https://lore.kernel.org/qemu-devel/CAJSP0QWF8g7r5VqU_PRbskWZ...

xemdetia 6y ago

Yeah, there's no discussion on this blog post of what a lot of people are doing in writing project-specific linters, static analysis passes, code generators and so on that just ensure higher code quality which to me is more bleeding edge when it comes to actually helping. There's also no mention of the fact QEMU is tightly bound to other C based projects like libvirt and KVM and having developers be able to switch back and forth is extraordinarily useful. It wouldn't just be replacing QEMU but also the ecosystem around QEMU. It's not like QEMU is the application at the end of a dependency chain, it's in the middle for a lot of users.

Ar-Curunir 6y ago

And maybe you should read the conclusion of the article before commenting on it?

pquerna 6y ago

Hello. I'm not a QEMU developer. I used to be pretty active in Apache HTTPD, APR and related projects. They are large user space code bases written in C - with, overall, a relatively OK security record. I think Apache should be on a path to be rewritten in Rust. Here's why... Every new line of C has a chance of a remotely exploitable vulnerability. No matter the precautions taken, no matter the developer who writes it. HTTPD has a long history, precautions like memory pools from APR and uses "safe" string functions, but it still has issues. Apache's core C code doesn't change much, so yes, many remotely exploitable memory corruption bugs have been fixed over 20+ years, but new code, new code still has bugs. And they can be bad. Look at the recent known vulnerabilities in httpd: https://httpd.apache.org/security/vulnerabilities_24.html https://httpd.apache.org/security/vulnerabilities_24.html Vulns that are largely fixed by Rust are concentrated areas like HTTP/2 support and the Proxy - areas under active development. Vulns around logical errors are still there, and more widespread, but largely have a lower impact. So, I emphasize with QEMU developers. I'm in the same boat. I have a full time job, and that job is not to work on Apache HTTPD. It would take a full time job to incrementally adopt Rust. The outcome would be in 24+ months, no more remote memory corruption bugs. Is it worth it to fund this? Can you put a price tag on this for the dozens of "core infrastructure" software projects written in C?

secondcoming 6y ago
No offense, but rewriting httpd in rust won't make it any better. There's no excuse for thread-per-connection in 2020.
- AgentME 6y ago
  That's not at all the issue they said that Rust would help with.
  - secondcoming 6y ago
    Yes but porting httpd to another language would just be putting lipstick on a pig!
- 6y ago

mmis1000 6y ago

> This raises the bar to learning the language, but I look at it this way: learning Rust is humanly possible, writing bug-free C code is not. It's simply impossible to write completely safe c code. Lots of bug like heart bleed, dirty cow, whatever, you name it was write by people that have dozens years of experiment and they still make accidents. Switch the language is expensive of course. But it might worth it eventually if this project continue to run for a long time (or the project got abandoned before it pays off, who knows?)