3 ms·

It seems this is the last version to have Nginx in the base install. 5.7 Will only ship their in-house httpd(8) as the default web server, although Nginx will s

• feld 12y ago
  Reyk also said that people could write papers on Nginx's http implementation because it's crazy how well optimized it is. There's a BSDNow.tv interview he brings this up and talks more about the change away from Nginx.
• gioele 12y ago
  > [nginx] uses custom memory allocators (for performance reasons) and it is wrapping or replacing standard C library functions all over the place. This could eliminate some of our built-in security mechanisms. Isn't this what made most of OpenSSL bugs possible and made them go unnoticed for a long time?
  • haberman 12y ago
    And yet techniques like custom memory allocators can have compelling performance benefits. To me the right tradeoff is: if you want to do fancy allocation, at least make the allocator injectable so that people can use standard malloc (or even a specialized security-hardened malloc) if they prefer. Robust low-level libraries like Lua, zlib, etc. usually take this approach: you can pass a pointer to a custom "malloc" function. Unfortunately this isn't always possible: LuaJIT doesn't support the "custom allocator" part of the Lua API for a couple of reasons: http://www.freelists.org/post/luajit/Why-does-LuaJIT-have-its-own-allocator http://www.freelists.org/post/luajit/Why-does-LuaJIT-have-it... https://gist.github.com/nddrylliog/8722197 https://gist.github.com/nddrylliog/8722197
    • aortega 12y ago
      For critical system daemons, using a custom memory allocator that disables the in-built system security is insane. Injectable allocators that fill the heap with function pointers in predictable positions are what make exploiting them easy.
      • masklinn 12y ago
        On the other hand, as far as I know most systems don't bundle security features in their standard allocators. I'm not sure any non-bsd system does.
        • throwaway2048 12y ago
          Both OSX and especially Windows have extensive memory security features baked into their system allocators (ASLR, SSP, NX bit support, Guard pages, background page zeroing, etc) and even glibc has some basic security features. Its kind of funny that windows is way ahead of your average linux distro on this front, considering the typical attitude with regards to how secure one is compared to the other. Also its not really the BSDs that have these types of security features, its pretty much exclusively OpenBSD. FreeBSD has code support for several of these features but it is not enabled by default, and tends to break things badly when it is enabled, although work is (finally) being done to fix this situation.
          • Hello71 12y ago
            ASLR: enabled by default on virtually all Linux systems, can be improved with the installation of PaX. disabled by default on Windows systems. KASLR: Windows has it, Linux does too, but only since 3.14. SSP: libc specific, but MSVS since 2003 has basic stack-smashing support similar to gcc's -fstack-protector which has been enabled in Debian-based distros for many years, and is now being improved over MSVC /GS with -fstack-protector-strong. NX bit support: Support added around 2004 or XP. Again, PaX is far stronger than Windows here. "Guard pages": This is SSP with a different name. So at best, we can say that Windows added some security features slightly earlier, but has lagged in updating them to new standards.
  • aortega 12y ago
    >Isn't this what made most of OpenSSL bugs possible and made them go unnoticed for a long time? Yes, and samba, and firefox. Replacing the standard C memory allocator is a stupid idea.
    • angersock 12y ago
      Replacing the standard C memory allocator is a stupid idea. Incorrect. There are a lot of reasons (for tracing, for debugging, for providing fast allocations, etc.) for replacing the standard malloc() implementation in a given program. Simply put, recall that that allocator has to be good-enough for the general case, and as such cannot be the best for any particular case. It's tricky to get right, but it's hardly a "stupid idea".
  • eksith 12y ago
    I believe so. OpenSSL had a whole swath of other issues that contributed to its problems, but chief among them was a habit of implementing core functionality already provided by the OS. Also, as mentioned, the constantly lengthening codebase made checking for such issues difficult. OpenBSD folks have worked hard to make their functions safe and it would be a shame if a duplicate function led to a vulnerability that didn't exist in the core.