Forgot your password?
typodupeerror
BSD

Interview: Ask Theo de Raadt What You Will 290

Posted by samzenpus
from the go-ahead-and-ask dept.
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.
This discussion has been archived. No new comments can be posted.

Interview: Ask Theo de Raadt What You Will

Comments Filter:
  • by bluefoxlucid (723572) on Wednesday March 05, 2014 @01:43PM (#46410101) Journal

    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.

  • by carlhaagen (1021273) on Wednesday March 05, 2014 @01:45PM (#46410129)
    There is no need for third-party tools for what you want to achieve. While the solution is a bit ungainly, all of it is already supported by OpenSSH and its sftp subsystem. This is how I configured things on my system:

    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 /sbin/nologin as shell to deny them shell access. Their home directories should be owned by root:sftponly, and within the home dir you then create relevant user-controllable directories which should be owned by :sftponly.

    Secondly, the sshd_config magic that makes the whole charade work:

    Subsystem sftp /usr/libexec/sftp-server
    Match Group sftponly
    ForceCommand internal-sftp
    ChrootDirectory %h
  • by the_B0fh (208483) on Wednesday March 05, 2014 @04:32PM (#46412225) Homepage

    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.

  • by tlambert (566799) on Wednesday March 05, 2014 @05:06PM (#46412651)

    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

  • by david_thornley (598059) on Wednesday March 05, 2014 @07:40PM (#46414115)

    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.

You are an insult to my intelligence! I demand that you log off immediately.

Working...