|
Home > Archive > Unix Programming > February 2006 > Is mprotect() defined in POSIX
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is mprotect() defined in POSIX
|
|
|
|
|
|
| loic-dev@gmx.net 2006-02-19, 8:29 am |
| Hi Nudge,
> Is mprotect() defined in POSIX?
mprotect() has been introduced with Posix.1b aka IEEE std 1003.1b 1993.
> http://www.opengroup.org/onlinepubs...h/mprotect.html
>
> It seems to be part of the Single UNIX Specification, but I don't
> know how it relates to POSIX.
SUS is a superset of POSIX that places additional restrictions on the
options and limits in the POSIX specification.
In particular, SUS states that the POSIX option
_POSIX_MEMORY_PROTECTION must be provided, which just means that the
function mprotect() is defined.
In other word, if your implementation conforms to the SUS standard, in
which case it is said to be UNIX branded, then it will have the
mprotect() function.
By the way, you might want to read the current version of the SUS
standard to be found at: http://www.unix.org/version3/online.html
HTH,
Loic
| |
| Nudge 2006-02-19, 10:32 am |
| Loic wrote:
> Nudge wrote:
>
>
> mprotect() has been introduced with Posix.1b aka IEEE std 1003.1b 1993.
>
>
>
> SUS is a superset of POSIX that places additional restrictions on the
> options and limits in the POSIX specification.
>
> In particular, SUS states that the POSIX option
> _POSIX_MEMORY_PROTECTION must be provided, which just means that the
> function mprotect() is defined.
>
> In other word, if your implementation conforms to the SUS standard, in
> which case it is said to be UNIX branded, then it will have the
> mprotect() function.
>
> By the way, you might want to read the current version of the SUS
> standard to be found at: http://www.unix.org/version3/online.html
(Thanks for the information.)
The reason I asked is because, in another group, someone claimed
self-modifying code was not allowed on modern operating systems.
Can you name a few OSes that explicitely disallow SMC?
Is mprotect() allowed to fail when invoked with PROT_EXEC|PROT_WRITE
| |
| Barry Margolin 2006-02-19, 5:50 pm |
| In article <43f895fb$0$5608$626a54ce@news.free.fr>,
Nudge <honeypot@kma.eu.org> wrote:
> The reason I asked is because, in another group, someone claimed
> self-modifying code was not allowed on modern operating systems.
What they probably mean is that writing to the text segment, and
executing the stack or data segments, are prohibited BY DEFAULT. But
system calls like mprotect() can be used to override the default for the
current application when desired. Note that this cannot generally be
exploited by buffer-overflow attacks, because they depend on executing
the stack to run the exploit in the first place -- the attack would have
to be on an application that already disables the protection before
running into the overflow.
> Is mprotect() allowed to fail when invoked with PROT_EXEC|PROT_WRITE
Why don't you just read the specification and see?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Igmar Palsenberg 2006-02-20, 7:48 am |
| Nudge wrote:
> The reason I asked is because, in another group, someone claimed
> self-modifying code was not allowed on modern operating systems.
>
> Can you name a few OSes that explicitely disallow SMC?
OpenBSD might be one of them, linux with selinux / grsec patches can be
configured to disallow them.
> Is mprotect() allowed to fail when invoked with PROT_EXEC|PROT_WRITE
Yes.
Igmar
| |
| Geoff Clare 2006-02-20, 5:54 pm |
| loic-dev@gmx.net wrote, on Sat, 18 Feb 2006 13:56:19 -0800:
>
> SUS is a superset of POSIX that places additional restrictions on the
> options and limits in the POSIX specification.
Nit-pick: that's not strictly true any more. It was the case for
SUSv2 and POSIX.1-1996 which were separate documents, but SUSv3 and
POSIX.1-2001 are one and the same document. That one document
defines requirements that all POSIX systems must meet and defines
additional requirements that are optional for POSIX conformance but
which UNIX systems must meet.
--
Geoff Clare <netnews@gclare.org.uk>
| |
| Casper H.S. Dik 2006-02-20, 5:54 pm |
| Igmar Palsenberg <igmar@jdimedia.local> writes:
>Nudge wrote:
[vbcol=seagreen]
>OpenBSD might be one of them, linux with selinux / grsec patches can be
>configured to disallow them.
None of them disallow self-modifying code but many OSes will attempt
to limit the number of pages with are rwx (and either have "r-x" or "rw-"
pages).
There's little point in interfering with mprotect() as that presupposes
you are already in control of the CPU and so the mprotect cannot be
the result of code injection.
[vbcol=seagreen]
>Yes.
Yes, of course, but I think all of the above mentioned OSes still
allow you to mmap struff RWX.
The main reason why self modifying code is not within the realm of
standards is because it gets you into architecture specific territory
pretty quickly. (Whether you need to flush the instruction cache or
do other magic before you can run the recently modified code and such)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Igmar Palsenberg 2006-02-20, 5:54 pm |
| Casper H.S. Dik wrote:
>
> None of them disallow self-modifying code but many OSes will attempt
> to limit the number of pages with are rwx (and either have "r-x" or "rw-"
> pages).
>
> There's little point in interfering with mprotect() as that presupposes
> you are already in control of the CPU and so the mprotect cannot be
> the result of code injection.
grsec limits how an exec can modify certain sections in memory : You
can't change the code section (ro), and data section is non-exec. When
properly configured, an application can't change this, and a violation
results in a segv.
>
>
> Yes, of course, but I think all of the above mentioned OSes still
> allow you to mmap struff RWX.
Yes, but then you're asking for it : Just mapping a page, and changing
it isn't allowed in most cases.
> The main reason why self modifying code is not within the realm of
> standards is because it gets you into architecture specific territory
> pretty quickly. (Whether you need to flush the instruction cache or
> do other magic before you can run the recently modified code and such)
The JVM is one with does these things. The valgrind mailing list is an
interesting thing to read when it comes to this, since VG will most
likely fail when these hacks are done 
> Casper
Igmar
|
|
|
|
|