Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29620
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 212.55.154.21 cause and error)
Message-ID: <00d101c79bb5$ef107ed0$0100a8c0@pc07653>
To: "Stefan Esser" <sesser@hardened-php.net>,
	"Stanislav Malyshev" <stas@zend.com>,
	"PHP internals" <internals@lists.php.net>
References: <465022BE.1020905@hardened-php.net> <4651351D.8010306@zend.com> <46513D1C.2030104@hardened-php.net>
Date: Mon, 21 May 2007 15:39:56 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-15";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dismantling the lies...
From: nlopess@php.net ("Nuno Lopes")

>> I don't imagine how one really could calculate maximum depth without
>> solving the halting problem, so I must be missing something. I ask
>> somebody who knows what these patches are to send me a link - if there
>> were patches that do that automatically for any code I would very much
>> like to see them.
>> Adding the arbitrary - even configurable - limit doesn't seem to me the
>> correct solution, since it has high potential to break application code
>
> Maybe I was a bit unspecific. If I recall correctly Nuno had some patch
> (or was it someone else) that was keeping track of depth and maximum
> stack size
> and was deciding on the fly if another step deeper could crash. Of
> course you need some sane detection.

For the record the patch I had is this: 
http://mega.ist.utl.pt/~ncpl/zend_stack_protection.txt (it shouldn't apply 
cleanly due to some changes in zend_try some time ago).
The approach of this patch is not to know in advance if there's still 
available stack, but rather catch the SIGSEGV and bailout. I used this 
approach in order to catch problems in external libraries, too. By that time 
I was thinking in pcre, which was pretty easy to segfault with user-provided 
data (now this is not the case because its internal recursion depth can be 
limited - although with a PHP_INI_ALL config).
This approach is not very portable though, and by the time I was told that 
probably it wouldn't play well with Apache signal handlers.

Knowing in advance if you can recurse or not doesn't sound much difficult in 
theory.. You can get the limit (e.g. with getrlimit) then you can know how 
much stack does a function call take, and then you can use a heuristic to 
make the decision. This isn't 100% secure though (the limited depth approach 
isn't too), but it's an option. I would love to ear how other VMs handle the 
problem, like the JVM, anyone?

Nuno