mprotect(2) clears the flag for whole page which causes program crash.

[Sharad Chandra]

Hi,

mportect clears the exec flag of whole page by which my program crashed. I am
attaching sample code. It is performing below task

1) allocate memory1
2) allocate memory2
3) change permission of memory 1 and 2 to exec by mprotect.
4) clear the exec permission of memory 1 and free it.
5) execute the memory2 by mapping to pointer function.
6) clear the exec permission of memory 2 and free it.

Program crashed at step 5 if memory 1 and 2 are in same page.

$ uname -a
FreeBSD app164.in.niksun.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1
07:18:07 UTC 2009
ro...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

$ gcc -g -o test -Wall mprotect.c
$ ./test
mem1 at: 34369183888
mem2 at: 34369183892
address difference: 4
test_func1 function returned 0
test_func2 will crash here
Segmentation fault (core dumped)

Is it known bug or is there any workaround? How will a userland process make
sure that process will not crash as malloc(3) can allocate where ever it get
the memory free to use.

--
Thanks,
Sharad Chandra

[Kostik Belousov]

Attachment was stripped. Anyway, mprotect(2) works on the page granularity.
The first sentence from the mprotect manpage says:
The mprotect() system call changes the specified pages to have
protection prot.

By design, mprotect uses hardware capabilities of the processor' MMU
to enforce the protection, and MMU works on the page granularity.

[Robert Watson]

On Tue, 17 Nov 2009, Sharad Chandra wrote:

> Is it known bug or is there any workaround? How will a userland process make
> sure that process will not crash as malloc(3) can allocate where ever it get
> the memory free to use.

mprotect(2) operates on pages, so you'll want to use mmap(2) and munmap(2) to
allocate and free pages directly rather than mallac(3), which manages byte
ranges from pages managed using those same interfaces.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Sharad Chandra]

,---- [Jung-uk Kim wrote:]

| On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote:
| > On Tue, 17 Nov 2009, Sharad Chandra wrote:
| > > Is it known bug or is there any workaround? How will a userland
| > > process make sure that process will not crash as malloc(3) can
| > > allocate where ever it get the memory free to use.
| >
| > mprotect(2) operates on pages, so you'll want to use mmap(2) and
| > munmap(2) to allocate and free pages directly rather than
| > mallac(3), which manages byte ranges from pages managed using those
| > same interfaces.
|

| For example:
|
| http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471
|

Thanks everyone. mmap(2) worked and program did not crash. Only problem with
it I use only fraction of allocated memory (each request alocate minimum of
one page and my request is in hundreds), rest is waste of it so no one else
will get this memory to use. And if a process runs as daemon and makes many
request, It can hold a lot of it. Just a question floated in mind.

Many thanks,
Sharad Chandra

[Robert N. M. Watson]

On 19 Nov 2009, at 10:57, Sharad Chandra wrote:

> Thanks everyone. mmap(2) worked and program did not crash. Only problem with
> it I use only fraction of allocated memory (each request alocate minimum of
> one page and my request is in hundreds), rest is waste of it so no one else
> will get this memory to use. And if a process runs as daemon and makes many
> request, It can hold a lot of it. Just a question floated in mind.

One of the defining properties of pages is that they are the granularity at which access protections are controlled in hardware, so your choices are a minimum of one page per object, or having multiple objects that share the same protection properties. However, it could be that you could accomplish whatever your goals may be using techniques other than paging; for example, using ptrace(2) to instrument individual accesses, binary rewriting, a virtual machine, source code instrumentation, or other methods along those lines that have been used for debugging and security over the years.

Robert_______________________________________________

[Julian Elischer]

Sharad Chandra wrote:
> ,---- [Jung-uk Kim wrote:]
> | On Wednesday 18 November 2009 01:52 pm, Robert Watson wrote:
> | > On Tue, 17 Nov 2009, Sharad Chandra wrote:
> | > > Is it known bug or is there any workaround? How will a userland
> | > > process make sure that process will not crash as malloc(3) can
> | > > allocate where ever it get the memory free to use.
> | >
> | > mprotect(2) operates on pages, so you'll want to use mmap(2) and
> | > munmap(2) to allocate and free pages directly rather than
> | > mallac(3), which manages byte ranges from pages managed using those
> | > same interfaces.
> |
> | For example:
> |
> | http://docs.freebsd.org/cgi/mid.cgi?200911181926.nAIJQHOR081471
> |
>
> Thanks everyone. mmap(2) worked and program did not crash. Only problem with
> it I use only fraction of allocated memory (each request alocate minimum of
> one page and my request is in hundreds), rest is waste of it so no one else
> will get this memory to use. And if a process runs as daemon and makes many
> request, It can hold a lot of it. Just a question floated in mind.

write your own allocator that efficiently divides up the mmapped pages
among several requests?