A question about PROT_NONE on PPC and PPC64

[Jamie Lokier <jamie@shareable.org>]

Hi folks,

I'm doing a survey of the different architectural implementations of
PROT_* flags for mmap() and mprotect().  I'm looking at linux-2.6.5.

The PPC and PPC64 implementations are very similar to plain x86:
read implies exec, exec implies read and write implies read.

(Aside: Is the patch for making exec permission separate on its way
into the tree?)

I see a potential bug with PROT_NONE.  I'm not sure if it's real, so
could you please confirm?

PPC32
=====

In include/asm-ppc/pgtable.h, there's:

#define PAGE_NONE	__pgprot(_PAGE_BASE)
#define PAGE_READONLY	__pgprot(_PAGE_BASE | _PAGE_USER)

It appears the only difference betwen PROT_READ and PROT_NONE is
whether _PAGE_USER is set.

Thus PROT_NONE pages aren't readable from userspace, but it appears
they _are_ readable from kernel space.  Is this correct?

This means that calling write() with a PROT_NONE region would succeed,
instead of returning EFAULT as it should, wouldn't it?

If so, this is a bug.  A minor bug, perhaps, but nonetheless I wish to
document it.

I don't know if you would be able to rearrange the pte bits so that a
PROT_NONE page is not accessible to the kernel either.  E.g. on i386
this is done by making PROT_NONE not set the hardware's present bit
but a different bit, and "pte_present()" tests both of those bits to
test the virtual present bit.

PPC64
=====

In include/asm-ppc64/pgtable.h, there's:

#define _PAGE_BASE	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
#define PAGE_NONE	__pgprot(_PAGE_PRESENT | _PAGE_ACCESSED)
#define PAGE_READONLY	__pgprot(_PAGE_BASE | _PAGE_USER)

This looks very similar to PPC32: the main difference between
PROT_NONE and PROT_READ appears to be the _PAGE_USER flag.

So does this mean that PROT_NONE pages, although they aren't readable
from userspace, are readable from kernel space?  I.e. that write()
with a PROT_NONE region would succeed, instead of returning EFAULT as
it should?

I don't know whether the _PAGE_COHERENT flag is significant here.
Perhaps you use it in some clever way in the TLB handler to prevent
these pages from being present in the TLB?

Thanks,
-- Jamie