A question about PROT_NONE on PPC and PPC64

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

No. Kernel accesses to pages in the user portion of the address space (0 .. TASK_SIZE-1) are done using the user permissions. On classic PPC this is implemented (in part) by setting Ks = Kp = 1 in the segment descriptors for the user segments, which tells the hardware to check the access as if it was a user access even in supervisor mode.

We do the same on ppc64 as well.

If you do find a ppc32 or ppc64 machine where the write succeeds instead of returning EFAULT, let me know please.

Paul.

Hi Paul,

Gabriel Paubert tells me that PROT_NONE _might_ have the bug described below on the PPC 4xx and 8xx architectures, because their MMUs don't implement "Ks = Kp = 1" segments.

Can you or someone else confirm whether the potential bug occurs on PPC 4xx/8xx?

Thanks,
-- Jamie