Hacker News Reader

Comment by varbhat | Hacker News Reader

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.

View on HN

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.

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

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?

No offense, but rewriting httpd in rust won't make it any better. There's no excuse for thread-per-connection in 2020.

Good thing Apache has mpm_event https://httpd.apache.org/docs/2.4/mod/event.html

in a hilarious turn of events (to me at least), I was one of the primary developers of the event mpm.

Alright, so please correct me if I'm wrong then.

I cannot perform a non-blocking operation (querying redis for example) from within my module's handler function because as soon as my handler returns httpd sends a response. i.e. there's no 'NOT_DONE_YET' return code?

And while I'm anonymously ranting on the internet...

- being able to control response headers completely would be nice. In our case, the Date and Server headers cost money to send and our clients don't care about them. It's not for security reasons, it's about traffic egress costs on the cloud

- having a way to hook a worker thread's init would be useful

- there must be an easier way to get a request body other than the bucket brigade stuff?

1) You return SUSPENDED instead of OK from your handler. See also http://svn.apache.org/viewvc?view=revision&revision=1593860

2) You can control all response filters at the byte level with an Output Filter.

3) Hooks already exist for this: https://ci.apache.org/projects/httpd/trunk/doxygen/group__ho...

4) No. Bucket Brigades is the API for this. It's an efficient linked-list of future-data. It's a good API IMO, just needs some understanding, and because its in C, its full of macros (there are more alternatives to making it cleaner if we weren't using C)

1) potential gamechanger. Thanks for pointing it out

2) yes, but there's a config directive for the Server header too that could just allow people to turn it off

3) for child_init, but nothing obvious that maps to a worker_thread_init

Are there plans for httpd to avail of io_uring if the kernel provides it?

I will admit, I've struggled with configuring httpd for years. A single threaded redis server can handle more connections than a full httpd install.

LOL

That's not at all the issue they said that Rust would help with.

Yes but porting httpd to another language would just be putting lipstick on a pig!

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_PRbskWZ...

> 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?)

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.

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

Reply on news.ycombinator.com