Monday, February 12, 2007

Apache / IIS Flamebait

There's a ZDNet blog posting by Richard Stiennon that shows two call graphs comparing the system calls that a Linux / Apache server makes to serve up a simple page versus the equivalent on Windows / IIS.

Surprise, Apache makes fewer system calls. The argument is that this makes it easier to secure a Linux / Apache implementation. That might be true. My experience is that ignorant administration is an orders-of-magnitude greater threat than the inherent limitations of either platform.

While it's sort of an interesting look... I've got a few big problems with the post:
a) The graphs are unreadable, and therefore FUD. I'm sure it was just a bandwidth issue not to have a version of the graph with enough resolution to actually read the system calls being made. However, just showing two pictures with lots of lines and basing your conclusion on the fact that one picture has way more lines in it is a pretty shoddy argument. I'll give Stiennon the benefit of the doubt that he both analyzed the original graphs, and is qualified to understand what they say. If that's not the case, then shame on you for stirring up a pointless religious debate.
b) Microsoft chose this implementation on purpose. You can make an intellectually honest argument that keeping most processing in user-space is inherently more secure, but that's just a (sensible) opinion, and not gospel fact. IIS7 moved most low-level processing into http.sys as a conscious decision in support of performance and stability. ASP.Net can blow chunks and IIS will restart it. IIS can blow chunks and http.sys will queue up the requests until the OS restarts IIS. You would be right in assuming that this puts the entire OS at the mercy of any holes in http.sys. But in closed-source land that means that http.sys is going to be something that they pay extra-special attention to, and also insulate from the feature-itis that ASP.Net (and thus IIS) are prone to.

Alright, that's enough defending Microsoft (like they need my help). In Linux-land, there's a fanatical devotion to moving as much code as possible out of kernel-space and into user-mode. Security is one of the concerns, but it also keeps the kernel simple and light (well, simple as far as kernels go). This is a design decision that gets repeated in lots of Linux projects, but it comes at a price, like all design decisions do. Until the code can cross the magic line where really almost everything is happening in user-mode, there's a not-irrelevant performance cost from the marshaling between memory spaces. Apache already crossed that line... it's a good decision. And really, under the open source model where defense-in-depth is even more important, it's usually a good decision for most projects.

Of course, this is only a "decision" you get to make if you're hacking straight at the API. And if you're one of those people... you knew all this already. :)

Oh, and thanks to Arno for pointing me at the post.


admin said...

Isn't Apache written in C and IIS in OO C++... Which would translate into more calls?

Brian Deacon said...

Well, yes, yes, and not necessarily, but probably.

There's nothing about C++ that inherently means it will make more system calls. In fact, if your design goal was to minimize system calls, you could come up with an effective OO strategy in C++ that actually helped you do that.

In practice, however, most OO implementations follow the idea that you build something that does what you want and then you can start treating it like a black box. This is a Good Thing. The trade-off you make is that your maintainable, flexible code might not be as efficient in areas you weren't prioritizing.

Now that you mention it, though, the difference in the call graphs probably is a symptom of one implementation being in C and the other in C++. What looks like spaghetti when flattened to all the leaf calls is probably more organized when viewed from a higher level, and so not necessarily the security threat that Stiennon is claiming.

But on the other hand, IIS has historically had lots of security problems. A detailed study of those call graphs would be a start in actually making a claim about one platform over the other... but just a hand-waving post with an unreadable image with lots of lines doesn't actually move the ball down the field.