Interview: Ask Theo de Raadt What You Will 290
Theo de Raadt was a founding member of NetBSD, and is the founder and leader of the OpenSSH and OpenBSD projects. He is currently working on OpenBSD 5.5 which would be the projects 35th release on CDROM. Even though he'd rather be hiking in the mountains or climbing rocks in his free time, Theo has agreed to answer any question you may have. As usual, ask as many as you'd like, but please, one question per post.
Re:Why are you such an asshole? (Score:5, Informative)
How screwed up would the project be had he not been such an "asshole" as you describe?
Way back when, I brought up to the OpenBSD mailing list that position-independent executables (PIE) on x86 would incur a negligible performance penalty while increasing the effectiveness of certain security measures--the randomization of stack, library, and heap base--significantly.
Theo immediately pulled the discussion off-list to tell me that the optimization is "very expensive" (i.e. incurs a huge performance hit). He bolstered his argument by repeating, across 14 e-mails, "We invented this stuff, I know what I'm talking about" and "I don't even know who you are, everyone knows who I am".
Linux had oprofile.
I ran some measurements. The performance hit without relying on -fomit-stack-pointer was some 0.6%, and with -fomit-stack-pointer you got a 5.2% boost unrealized. We could call the raw performance hit 5.8%. -fPIE code is 5.8% slower.
Further, most programs spent substantially less than 0.2% of their execution time in the main executable. -fPIE only affects the main executable; multiplying this together gives us 0.2% * 5.8% = 0.0116%. This means that, in any one hour period, if you could find a total of 0.42 seconds of CPU time (i.e. CPU at 50% for 0.84 seconds, CPU at 0% for 0.42 seconds, etc.), -fPIE would have zero real impact. If your system is pegged at 100% for 24 hours, it will be pegged at 100% for 10 seconds longer. In 60 seconds, you need 0.0070 seconds of additional CPU time to handle this optimization.
In short: Theo was wrong. He derailed the conversation off-list probably because he didn't have a real argument and was afraid of being proven wrong. He's never admitted he was wrong, and probably considers the whole argument a moral victory.
The whole exchange has taught me that OpenBSD is just another nobody-fucking-cares OS with a bunch of shiny egostroke things like strlcpy() and probably less security than anything else. I wonder how many security holes have gone unseen, how many improvements have papered over unacknowledged previous issues, and so on. OpenBSD uses very specific language: only two remote exploits in the default installation in however many decades. That's because OpenBSD comes with everything switched off--like Ubuntu before Avahi--so there's no attack surface. It's great marketing, but it has no bearing on how much of the code base is secure or how risky it is to run OpenBSD vs Linux vs Windows.
Theo's manner says that the above assessment has a high probability of being valid. Not a majority probability, but a high probability: most people claim OpenBSD is "secure", and in fact I spent a time editing this out of Wikipedia because every security article cited OpenBSD--up to and including listing "use OpenBSD" under "ways to improve computer security". This was not NPOV, and I have found no empirical studies of OpenBSD security--Coverity hasn't even run their tools against the code base, and I've seen no widely published studies on number of practically exploitable local privilege escalations and shipped daemons and such comparing OpenBSD to FreeBSD and Linux and so on--so it was inappropriate. But it does say that the normal assessment is that OpenBSD is probably "secure"; and I find a lot of soft evidence suggesting that this assessment is not reliable without more hard scientific evidence. A lot has gone into showing why OpenBSD "is secure", and very little has gone into showing that it's "not as insecure".
Linus has a massive ego and can be harsh, but he admits this and admits he has been wrong and the culture around Linux is different. Linus is sub-optimal, and the poor handling of negotiation by the Grsecurity and PaX people stunted Linux security development for a while, as did a number of other things; but Theo is the quintessential off-the-deep-end egomaniac. His technical expertise is highly questionable.
Re:Smoother Chroot and Sftponly integ into OpenSSH (Score:5, Informative)
First off, add a group that you call f.e. "sftponly". New users that are to be allowed only sftp access should have "sftponly" as their login group, and have
Secondly, the sshd_config magic that makes the whole charade work:
Subsystem sftp
Match Group sftponly
ForceCommand internal-sftp
ChrootDirectory %h
Re:Why are you such an asshole? (Score:4, Informative)
Obviously someone who has never worked with Theo. Theo simply does not suffer fools and will call you out for being stupid.
That is it.
I have asked beginner level questions, and he had answered them politely. But if you come in with an attitude, or as a know-it-all and did not even bother to read the FAQ, he will treat you like the turd you are.
For whatever reason, people seem to think that's being an asshole. Theo's not your paid support monkey, and has no need to waste his time on people who refuse to read.
Re:Why are you such an asshole? (Score:4, Informative)
Way back when, I brought up to the OpenBSD mailing list that position-independent executables (PIE) on x86 would incur a negligible performance penalty while increasing the effectiveness of certain security measures--the randomization of stack, library, and heap base--significantly.
Theo immediately pulled the discussion off-list to tell me that the optimization is "very expensive" (i.e. incurs a huge performance hit). He bolstered his argument by repeating, across 14 e-mails, "We invented this stuff, I know what I'm talking about" and "I don't even know who you are, everyone knows who I am".
Linux had oprofile.
I ran some measurements. The performance hit without relying on -fomit-stack-pointer was some 0.6%, and with -fomit-stack-pointer you got a 5.2% boost unrealized. We could call the raw performance hit 5.8%. -fPIE code is 5.8% slower.
Was this profiling done on Linux or OpenBSD?
The reason I ask is that the Linux model for 32 bit is to have a 4G/4G address space, where the user and kernel address space are completely disjoint, while the OpenBSD model was to have (initially) a 2G/2G split, later followed by a 3G/1G split.
With a disjoint address space, you aren't going to see tremendous performance degradation by going to PIE, even though you lose a register over it in 32 bit executables, since you are already paying the TLB flush overhead for the overlapping address spaces, and you are already paying the CR3 reload overhead for the mapping of copy buffers for the copyin/copyout operations. Assuming you do lazy mapping for the copy regions, you'll mask a pretty big chunk of the overhead, if the only activity you have on your system is your benchmarking process, as opposed to paying to move the copy window mappings around if you are doing a lot of context switching between processes that have even modest copyin/out requirements.
The overall overhead of this, according to Ingo Molnar, amounts to some 38% performance increase if you do not use a disjoint address space and copy windows.
This is practically the same performance you get from moving the kernel high (i.e. effectively, a negative offset) in a 64 bit system.
In addition, as long as you work around the Intel architecture TLB flush bug for the large vs. small page mappings covering the same physical memory region (i.e. the TLB flush would leave one of the TLB unflushed, and this is what caused issues with large page support to cover the kernel address space to get the TLB regions non-intersecting), you can get another up to 11% performance improvement by supporting all large pages in kernel space and all small pages in user space.
I suspect that the suggestion didn't get traction for 2 reasons:
(1) The above performance considerations, which were architecturally a performance win that OpenBSD could have and Linux couldn't, in the default case, for the default kernel and user address space mapping made the hit considerably more than the Linux-observed 5.8% on OpenBSD.
(2) ASLR (Address Space Layout Randomization), which is the primary reason for supporting PIE, is a means of security through obscurity, which relies on hiding the locations from the attack vectors, rather than actually having the code be secure, which is somewhat antithetical to normal security philosophy, which disdains obscurity as a protection mechanism (i.e. You can work around it using a relative return, unless you set the NX bit on all your DS/SS pages, which you should probably be doing anyway -- rendering the technique unnecessary in the first place).
I admit that PIE can be handy when you override shared libraries on the command line with environment variables passed to the run time linker, particularly for testing, but as a default mechanism, it's something of a dead end, particularly now that many architectures are taking the ARM 9 approach of a modified Harvard architecture. You can do a similar thing on recent Intel processors, although the recovery from a fault is you h
Re:Why are you such an asshole? (Score:4, Informative)
FUD about licensing issues? The BSDs are under non-copyleft licenses, and can't use code released only under the GPL. That's a matter of legality, not an issue that can bet settled. If archangels were to descend with the perfect device code, blessed by God, Buddha, and Sheldon Cooper, but it released only under the GPL, neither Theo nor Microsoft could touch it.