• Jason Baron's avatar
    [PATCH] make PROT_WRITE imply PROT_READ · df67b3da
    Jason Baron authored
    Make PROT_WRITE imply PROT_READ for a number of architectures which don't
    support write only in hardware.
    
    While looking at this, I noticed that some architectures which do not
    support write only mappings already take the exact same approach.  For
    example, in arch/alpha/mm/fault.c:
    
    "
            if (cause < 0) {
                    if (!(vma->vm_flags & VM_EXEC))
                            goto bad_area;
            } else if (!cause) {
                    /* Allow reads even for write-only mappings */
                    if (!(vma->vm_flags & (VM_READ | VM_WRITE)))
                            goto bad_area;
            } else {
                    if (!(vma->vm_flags & VM_WRITE))
                            goto bad_area;
            }
    "
    
    Thus, this patch brings other architectures which do not support write only
    mappings in-line and consistent with the rest.  I've verified the patch on
    ia64, x86_64 and x86.
    
    Additional discussion:
    
    Several architectures, including x86, can not support write-only mappings.
    The pte for x86 reserves a single bit for protection and its two states are
    read only or read/write.  Thus, write only is not supported in h/w.
    
    Currently, if i 'mmap' a page write-only, the first read attempt on that page
    creates a page fault and will SEGV.  That check is enforced in
    arch/blah/mm/fault.c.  However, if i first write that page it will fault in
    and the pte will be set to read/write.  Thus, any subsequent reads to the page
    will succeed.  It is this inconsistency in behavior that this patch is
    attempting to address.  Furthermore, if the page is swapped out, and then
    brought back the first read will also cause a SEGV.  Thus, any arbitrary read
    on a page can potentially result in a SEGV.
    
    According to the SuSv3 spec, "if the application requests only PROT_WRITE, the
    implementation may also allow read access." Also as mentioned, some
    archtectures, such as alpha, shown above already take the approach that i am
    suggesting.
    
    The counter-argument to this raised by Arjan, is that the kernel is enforcing
    the write only mapping the best it can given the h/w limitations.  This is
    true, however Alan Cox, and myself would argue that the inconsitency in
    behavior, that is applications can sometimes work/sometimes fails is highly
    undesireable.  If you read through the thread, i think people, came to an
    agreement on the last patch i posted, as nobody has objected to it...
    Signed-off-by: default avatarJason Baron <jbaron@redhat.com>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Roman Zippel <zippel@linux-m68k.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: default avatarAndi Kleen <ak@muc.de>
    Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
    Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
    Cc: Ian Molton <spyro@f2s.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    df67b3da
fault.c 11.9 KB