Re: Understanding Linux addr space, malloc, and heap

From: Vincent W. Freeh
Date: Fri Oct 21 2005 - 10:38:26 EST


The point of the code is to show that one can protect malloc code. It is a short example. It is not my application. The comments criticising the code are the beside the point.

One can mprotect malloc'd pages. My code does it. The mprotect man page does it.

But I can't mprotect the 66th page I malloc. And mprotect fails SILENTLY!

Is this interesting or not? Does anyone understand why?

Thanks,
vince.

Arjan van de Ven wrote:
On Fri, 2005-10-21 at 11:11 -0400, Vincent W. Freeh wrote:

Arjan van de Ven wrote:

On Fri, 2005-10-21 at 09:45 -0400, Vincent W. Freeh wrote:


Thanks for your quick response. It basically confirmed that I observed what I thought I did. However, I am no closer to solving my problem. I cannot mprotect data that I malloc beyond the first 65 pages.


you can't mprotect malloc() memory period ..

Actually, I can and do. Simple program at end.


Ok I meant in the "while adhering to the standard" :)



I call mprotect and it return 0--meaning it succeeded. But the permissions on the page remain rw. So it fails to change the permissions, but doesn't give any indication of this.

Thanks,
vince.

------------------
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
void *p;
int pgsize = getpagesize();

p = malloc(1024);
mprotect((void*)((unsigned)p & ~(pgsize-1)), 1024, PROT_NONE);
printf("\t*p = %d\n", *(int *)p);
return 0;
}


this has a bug, the 1024 is wrong... what if your "p" point actually
spans 2 pages?

but to have "some effect" even for malloc-falling-back-to-mmap..
just there's a bunch of collateral damage since you mprotect more than
just the memory you got from malloc. mprotect works on page size.. so if
p spans 2 pages (why wouldn't it ;) you mprotect either the wrong memory
(as in your example) or too much (eg both pages)...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/