Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29602
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <4651446B.3030805@zend.com>
Date: Mon, 21 May 2007 00:04:11 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Stefan Esser <sesser@hardened-php.net>
CC: PHP internals <internals@lists.php.net>
References: <465022BE.1020905@hardened-php.net> <4651351D.8010306@zend.com> <46513D1C.2030104@hardened-php.net>
In-Reply-To: <46513D1C.2030104@hardened-php.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dismantling the lies...
From: stas@zend.com (Stanislav Malyshev)

> 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

I would very much like to know how he does that. If the solution does 
not involve arbitrary stack limits then I think it's acceptable.

> course you need some sane detection.
> Other languages like Python or Perl (I actually don't remember which one
> of the two is protected) have a stack depth protection, and live happily
> with it.

As far as I can see on my tests, Perl just runs out of memory. 
Apparently PHP uses more stack than Perl. The result more or less the 
same anyway - script just dies.

> And the arbitrary limit argument. Well if you write portable PHP code
> you have an arbitrary limit anyway. IIRC on some Solaris Sparc systems
> the crash limit was at 800.

The problem is I see no generic way to know that "legitimate" 
applications would run with the limit and illegitimate won't. I.e. 
nothing prevents one from setting the limit to 1000 on solaris and get 
the same crashes, or from having legitimate application which goes more 
than 256 levels deep. If we could make the limit not arbitrary but based 
on capabilities of concrete system - then it would be very useful.

> deactivated by default is that without knowing
> the system and code it is hard to detect a sane limit. I personally

exactly. And if it's disable by default 99% of installations would have 
it run with default and thus such protection would be not much of a use. 
It's not only without knowing - even having the system it might be not 
that easy to figure it out - different calls consume different amount of 
stack, especially if there are internal functions in between.

> believe that 256 is enough for everyone.

I'm not sure it is. If there's an app which, for example, recursively 
parses data structures, I don't see why it can't be more than 256 levels 
deep. Good solution would be rely to real limits.
-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/