if it's like that in grsec/pax, it's also in linux-vserver + grsec
patches, since i use those as a base for patching the combo's...
grtzzz...
Rik Bobbaers
-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware/DR admin
> 2009/9/30 Natanael Copa <natanael.copa@gmail.com>:
>> On Tue, 2009-09-29 at 19:36 +0200, Romain Riviere wrote:
>>> Hello there,
>>>
>>> More feedback on this nasty issue : it's *SOLVED* ! The bad news is, I
>>> can blame it on the VServer+GrSec patch. The good news is, it's just
>>> the grsec part.
>>>
>>> After perusing the patch source a little, I had a hunch that PaX was
>>> interfering here, especially SEGMEXEC. And what do you know, one
>>> kernel with CONFIG_PAX_SEGMEXEC unset later, PHP is happily using
>>> exactly the amount of memory it should.
>>>
>>> Further debugging is not exactly in my league :-)
>>
>> Does this affect the grsecurity alone or does it only affect the vserver
>> +grsecurity combo?
>>
>> Did you report it back to the grsecurity maintainers?
>
> I asked spender and he he added a comment on
> http://bugs.php.net/bug.php?id=49501
> seems its more of a SEGMEXEC feature than a bug :
> "Due to VMA mirroring, the SEGMEXEC option causes accounted vm usage
> to double. So you weren't experiencing a memory leak -- you were just
> being accounted for twice as much memory as you thought you were using.
> The solution would be to double the resource limit or, if your system is
> NX-capable and PAE is enabled, use PAGEEXEC.
> -Brad"
>
Received on Wed Sep 30 13:38:42 2009