[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Jan 2012 11:38:46 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: %optflags for new gcc
Pavel,
Thank you for your comments! Unfortunately, this -z now stuff is by far
not a priority for us right now - as you can see from the recent lack of
discussions in here, development mostly stalled for a while now, and we
need to correct that. We have several pending tasks, with -z now being
further down the list.
On Sat, Jan 14, 2012 at 01:45:07PM +0800, Pavel Labushev wrote:
> 07.11.2011 04:19, Solar Designer wrote:
>
> > Yet 10% is significant for some uses - e.g., think CGI scripts written
> > in Perl.
>
> Please, do real-world tests. 10% slower startup time isn't significant in
> most cases, where interpreter startup time is about 0.1-30% of total
> execution time of a script that does do something real.
Actually, I think 90% being wasted on interpreter startup is not too
uncommon. Some scripts do something real (desirable), yet trivial.
On the other hand, the 10% figure I had mentioned is reduced to 6% on my
newer tests with:
#!/bin/sh
export LD_BIND_NOW=yes
for n in {1..1000}; do
perl -e 'print "hello\n"'
done | wc
(where I comment out the "export LD_BIND_NOW=yes" line to get the 6%
faster speed).
BTW, does LD_BIND_NOW give us the exact same security benefits as -z now
or not? I guess there's a difference for SUID/SGID programs (where the
invoking user might be the attacker, who will simply reset LD_BIND_NOW),
but excluding those from the comparison and assuming that LD_BIND_NOW is
in fact set, is there any security difference between these two approaches?
> Why support obsolete interfaces like CGI and lazy-bind general purpose apps
> in favor of few unrealistic use cases where anything performance-sensitive
> supposed to be running in form of a CGI script?
These are not unrealistic use cases. These are most common for Owl +
LAMP systems that our clients use right now.
> Not only php-fpm and mod_php
> are much faster than CGI by themselves, but, unlike CGI, they allow bytecode
> caching.
Yes. We support FastCGI + APC in our unofficial LAMP packages for Owl,
and we're making use of that on some virtual hosts, but most run plain
CGI for a variety of reasons. These reasons include: changes taking
effect immediately with plain CGI, memory usage/waste on APC caches per
each child process (no shared cache support yet), instant return of
memory allocated by scripts back to the system upon script termination,
occasional subtle issues with certain libraries when invoked multiple
times from a long-living process (e.g., we had a case of GD starting to
produce wrong-colored images, which is avoided with plain CGI
initializing it anew each time). Of course, you can say that there's a
different fix to each one of these issues and you'll be right, but the
reality is that most real-world web servers that we manage run plain CGI
for most of their virtual hosts right now. Maybe the problem is us (our
approaches to setting these systems up), but even if so I suspect that
it may be similar for many other Owl users.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
