Messages in this thread Patch in this message | | | Date | Thu, 29 Jun 2006 17:00:05 -0400 (EDT) | From | Jason Baron <> | Subject | Re: make PROT_WRITE imply PROT_READ |
| |
On Thu, 29 Jun 2006, Pavel Machek wrote:
> Hi! > > > > > PROT_READ to be used or implicitly adding it. Don't confuse people > > > > with wrong statement like yours. > > > > > > Can you quote part of POSIX where it says that PROT_WRITE must imply > > > PROT_READ? > > > > I don't believe POSIX cares either way > > > > "An implementation may permit accesses other than those specified by > > prot; however, 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." > > > > However the current behaviour of "write to map read might work some days > > depending on the execution order of instructions" (and in some cases the > > order that the specific CPU does its tests for access rights) is not > > sane, not conducive to application stability and not good practice. > > Well, some architectures may have working PROT_WRITE without > PROT_READ. If you are careful and code your userland application in > assembly, it should work okay. > > On processors where that combination depends randomly depending on > phase of moon (i386, apparently), I guess change is okay. But the > patch disabled PROT_WRITE w/o PROT_READ on _all_ processors. > > Pavel >
ok, the following patch should make x86 self-consistent, making PROT_WRITE imply PROT_READ.
i can produce patches for other architectures, if people agree with this approach.
thanks,
-Jason
--- linux-2.6/arch/i386/mm/fault.c.bak 2006-06-29 16:48:25.000000000 -0400 +++ linux-2.6/arch/i386/mm/fault.c 2006-06-29 16:49:51.000000000 -0400 @@ -449,7 +449,7 @@ case 1: /* read, present */ goto bad_area; case 0: /* read, not present */ - if (!(vma->vm_flags & (VM_READ | VM_EXEC))) + if (!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))) goto bad_area; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |