A question about PROT_NONE on PPC and PPC64

A question about PROT_NONE on PPC and PPC64

[Jamie Lokier]

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

Re: A question about PROT_NONE on PPC and PPC64

[Paul Mackerras]

Jamie Lokier writes:

> 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?

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.

> 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?

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

Paul.

Re: A question about PROT_NONE on PPC and PPC64

[Jamie Lokier]

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

Paul Mackerras wrote:
> > 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?
> 
> 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.