4 ms·
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 - wi
by 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 agoNo offense, but rewriting httpd in rust won't make it any better. There's no excuse for thread-per-connection in 2020.
- AgentME 6y agoThat's not at all the issue they said that Rust would help with.
- secondcoming 6y agoYes but porting httpd to another language would just be putting lipstick on a pig!
- fanf2 6y agoGood thing Apache has mpm_event https://httpd.apache.org/docs/2.4/mod/event.html https://httpd.apache.org/docs/2.4/mod/event.html
- pquerna 6y agoin a hilarious turn of events (to me at least), I was one of the primary developers of the event mpm.
- secondcoming 6y agoAlright, 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?
- pquerna 6y ago1) You return SUSPENDED instead of OK from your handler. See also http://svn.apache.org/viewvc?view=revision&revision=1593860 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__hooks.html 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)
- secondcoming 6y ago