Re: make PROT_WRITE imply PROT_READ

[Jason Baron <jbaron@redhat.com>]

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/