On 31 Jul 2012 at 22:12, Michael Orlitzky wrote:
> I get nothing in my dmesg, which otherwise records most limit-based denials.
>
> Is there some way I can troubleshoot this? It works on amd64 with the
> same kernel hardening options.
an strace -f may help to see what exactly fails.
On 08/01/2012 06:56 AM, PaX Team wrote:
> On 31 Jul 2012 at 22:12, Michael Orlitzky wrote:
>
>> I get nothing in my dmesg, which otherwise records most limit-based denials.
>>
>> Is there some way I can troubleshoot this? It works on amd64 with the
>> same kernel hardening options.
>
> an strace
On 1 Aug 2012 at 8:41, Michael Orlitzky wrote:
> Thanks, here are strace -f logs from both the hardened box (where it
> fails) and a vanilla gentoo x86 VM (where it works).
mmap2(NULL, 30720, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memor
On 08/01/12 09:08, PaX Team wrote:
> On 1 Aug 2012 at 8:41, Michael Orlitzky wrote:
>
>> Thanks, here are strace -f logs from both the hardened box (where it
>> fails) and a vanilla gentoo x86 VM (where it works).
>
> mmap2(NULL, 30720, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_S
On 1 Aug 2012 at 9:56, Michael Orlitzky wrote:
> But, I'd ruled out the stack size limitation because resource oversteps
> are supposed to be reported:
it's not a resource overstep but simply not enough virtual address space
(either because it's too fragmented to fit such a big allocation or the
On 08/01/2012 05:29 PM, PaX Team wrote:
> On 1 Aug 2012 at 9:56, Michael Orlitzky wrote:
>
>> But, I'd ruled out the stack size limitation because resource oversteps
>> are supposed to be reported:
>
> it's not a resource overstep but simply not enough virtual address space
> (either because it's
