kern/64573: mmap with PROT_NONE, but still could be read

Mark W. Krentel krentel at dreamscape.com
Wed Apr 14 17:32:25 PDT 2004


As I understand it, mmap() is required to support the PROT_NONE
request and its #define'd constant.  Whether or not the OS can satisfy
that request depends, in part, on hardware.  Quoting IEEE Std 1003.1:

    If an implementation cannot support the combination of access types
    specified by prot, the call to mmap() shall fail.
    ...
    If the Memory Protection option is supported, the implementation shall
    not permit a write to succeed where PROT_WRITE has not been set or
    shall not permit any access where PROT_NONE alone has been set. The
    implementation shall support at least the following values of prot:
    PROT_NONE, PROT_READ, PROT_WRITE, and the bitwise-inclusive OR of
    PROT_READ and PROT_WRITE.

See:  http://www.opengroup.org/onlinepubs/007904975/functions/mmap.html

So, you can always ask for PROT_NONE, or any other odd combination of
options.  But if prot specifies some combination that the hardware or
OS can't support, then the syscall is supposed to fail.

The same bug in kern/64573 also happens with madvise().  Calling
madvise(..., MADV_WILLNEED) always adds read access as an undocumented
side effect.

> Files with mode 000 are still readable by root and the mode can be
> changed later to make the file more useful. You can't really say the
> same thing about mmap PROT_NONE.

Sure you can.  As long as the protection was included in open(), you
can increase it with mprotect().

> Is it even possible to implement PROT_WRITE&~PROT_READ or PROT_NONE on i386?

On the P2 and P3 that I tested on, I was able to achieve all four
combinations of read/write access or not.  I guess I didn't try exec.

But you're absolutely right that this varies by hardware.  Maybe
mmap() should be patched with some #ifdef's to account for these
differences in architecture.

--Mark


More information about the freebsd-bugs mailing list