Confusion regarding ARMv5 MMU access permissions

Confusion regarding ARMv5 MMU access permissions

[Sasha Sirotkin]

I'm trying to figure out how ARMv5 MMU access permissions work in 
general and on Linux in particular.

Table B4-1 MMU access permissions (from the ARM Architecture Reference 
Manual) does not make sense to me and trying to correlate it with
 * Permission translation:
 *  YUWD   AP    SVC    User
 *  0xxx  0x00    no acc    no acc
 *  100x  0x00    r/o    no acc
 *  10x0  0x00    r/o    no acc
 *  1011  0x55    r/w    no acc
 *  110x  0xaa    r/w    r/o
 *  11x0  0xaa    r/w    r/o
 *  1111  0xff    r/w    r/w

from armv3_set_pte_ext makes even less sense.

Can please anybody shed some light on this black magic?

What YUWD stand for? How AP from the above table relate to AP[0:1] bits 
in the ARM page table ? How should I read ARM MMU access permissions table:
S R APXa AP[1:0] Privileged permissions User permissions Description
0 0  0       0b00     No access No access All accesses generate 
permission faults
x x  0       0b01     Read/write No access Privileged access only
x x  0       0b10     Read/write Read only Writes in User mode generate 
permission faults
x x  0       0b11     Read/write Read/write Full access
0 0 1        0b00     - - RESERVED
0 0 1        0b01     Read only No access Privileged read only
0 0 1        0b10     Read only Read only Privileged/User read only
0 0 1        0b11     - - RESERVED

The S and R bits are deprecated in VMSAv6. The following entries apply 
to legacy systems only.

0 1 0 0b00 Read only Read only Privileged/User read only
1 0 0 0b00 Read only No access Privileged read only
1 1 0 0b00 - - RESERVED
0 1 1 0bxx - - RESERVED
1 0 1 0bxx - - RESERVED
1 1 1 0bxx - - RESERVED

And what does that x (don't care !?) mean ?

Thanks a lot, hope this is the right place to ask these kinds of questions.

Confusion regarding ARMv5 MMU access permissions

[Russell King - ARM Linux]

On Sat, Apr 10, 2010 at 12:36:13AM +0300, Sasha Sirotkin wrote:
> I'm trying to figure out how ARMv5 MMU access permissions work in  
> general and on Linux in particular.

If you're interested in ARMv5, only look at the ARMv5 documentation;
don't get confused by the later stuff because that's totally different.

> Table B4-1 MMU access permissions (from the ARM Architecture Reference  
> Manual) does not make sense to me

You really need to understand that table first.

> How AP from the above table relate to AP[0:1] bits in the ARM page table ?

This is covered in the ARMv5 ARM architecture reference manual.

Small pages (4K) have four sets of permission bits, one for each 1K of
the page.  So the two bits are replicated across all entries to ensure
that each 1K segment of a single 4K page has the same permissions.

Extended pages (again 4K) have a different layout, where there is one
single set of permission bits, and the freed bits are dedicated for
other purposes - which includes adding an APX bit.

> How should I read ARM MMU access permissions table:
>
> S R APXa AP[1:0] Privileged permissions User permissions Description
> 0 0  0       0b00     No access No access All accesses generate  
> permission faults
> x x  0       0b01     Read/write No access Privileged access only
> x x  0       0b10     Read/write Read only Writes in User mode generate  
> permission faults
> x x  0       0b11     Read/write Read/write Full access
> 0 0 1        0b00     - - RESERVED
> 0 0 1        0b01     Read only No access Privileged read only
> 0 0 1        0b10     Read only Read only Privileged/User read only
> 0 0 1        0b11     - - RESERVED

AP[1:0] give you the binary bit combinations for the permission bits.
For small pages, APX=0.

> and trying to correlate it with
> * Permission translation:
> *  YUWD   AP    SVC    User
> *  0xxx  0x00    no acc    no acc
> *  100x  0x00    r/o    no acc
> *  10x0  0x00    r/o    no acc
> *  1011  0x55    r/w    no acc
> *  110x  0xaa    r/w    r/o
> *  11x0  0xaa    r/w    r/o
> *  1111  0xff    r/w    r/w
>
> from armv3_set_pte_ext makes even less sense.

AP refers to the access permissions bits in the small page case; and
as you can see these are duplicated across the four 1K sub-pages.

> What YUWD stand for?

Young, User, Write, Dirty.  Young means that the page has not been aged
by the VM.  User means that the page is accessible from userspace.
Write means that userspace can write to the page, and Dirty means that
the page has been written to.

Since ARMs don't have support for 'young' and 'dirty' there's a translation
from these four bits to emulate the effect of them; if a page is not 'young'
we need to make any access fault.  If a page is not dirty, we need to make
any write cause a fault.

> The S and R bits are deprecated in VMSAv6. The following entries apply  
> to legacy systems only.
>
> 0 1 0 0b00 Read only Read only Privileged/User read only
> 1 0 0 0b00 Read only No access Privileged read only
> 1 1 0 0b00 - - RESERVED
> 0 1 1 0bxx - - RESERVED
> 1 0 1 0bxx - - RESERVED
> 1 1 1 0bxx - - RESERVED
>
> And what does that x (don't care !?) mean ?

x = don't care.

Confusion regarding ARMv5 MMU access permissions

[Alexander (Sasha) Sirotkin]

On Sat, Apr 10, 2010 at 12:54 AM, Russell King - ARM Linux <
linux@arm.linux.org.uk> wrote:

> On Sat, Apr 10, 2010 at 12:36:13AM +0300, Sasha Sirotkin wrote:
> > I'm trying to figure out how ARMv5 MMU access permissions work in
> > general and on Linux in particular.
>
> If you're interested in ARMv5, only look at the ARMv5 documentation;
> don't get confused by the later stuff because that's totally different.
>
> > Table B4-1 MMU access permissions (from the ARM Architecture Reference
> > Manual) does not make sense to me
>
> You really need to understand that table first.
>
I think I finally get it, although the fact that it mentions both ARMv5 and
ARMv6 (and there seems to be no document on ARMv5 alone) was a bit
confusing.

One more question, if you don't mind.

It is my understanding that Linux never changes S and R bits of CP15
register 1 which on ARMv5 affect memory protection along with AP bits, i.e.
they are 00 all the time?

If this is correct, than if I wanted to mark a certain page as read-only for
both kernel and user modes, which  means setting AP bits to 00 and R bit of
CP15 reg 1 to 1, I'd have to reset the MMU - or in other words, this pretty
much impossible?

Thanks a lot, your previous email was extremely helpful.

>
> > How AP from the above table relate to AP[0:1] bits in the ARM page table
> ?
>
> This is covered in the ARMv5 ARM architecture reference manual.
>
> Small pages (4K) have four sets of permission bits, one for each 1K of
> the page.  So the two bits are replicated across all entries to ensure
> that each 1K segment of a single 4K page has the same permissions.
>
> Extended pages (again 4K) have a different layout, where there is one
> single set of permission bits, and the freed bits are dedicated for
> other purposes - which includes adding an APX bit.
>
> > How should I read ARM MMU access permissions table:
> >
> > S R APXa AP[1:0] Privileged permissions User permissions Description
> > 0 0  0       0b00     No access No access All accesses generate
> > permission faults
> > x x  0       0b01     Read/write No access Privileged access only
> > x x  0       0b10     Read/write Read only Writes in User mode generate
> > permission faults
> > x x  0       0b11     Read/write Read/write Full access
> > 0 0 1        0b00     - - RESERVED
> > 0 0 1        0b01     Read only No access Privileged read only
> > 0 0 1        0b10     Read only Read only Privileged/User read only
> > 0 0 1        0b11     - - RESERVED
>
> AP[1:0] give you the binary bit combinations for the permission bits.
> For small pages, APX=0.
>
> > and trying to correlate it with
> > * Permission translation:
> > *  YUWD   AP    SVC    User
> > *  0xxx  0x00    no acc    no acc
> > *  100x  0x00    r/o    no acc
> > *  10x0  0x00    r/o    no acc
> > *  1011  0x55    r/w    no acc
> > *  110x  0xaa    r/w    r/o
> > *  11x0  0xaa    r/w    r/o
> > *  1111  0xff    r/w    r/w
> >
> > from armv3_set_pte_ext makes even less sense.
>
> AP refers to the access permissions bits in the small page case; and
> as you can see these are duplicated across the four 1K sub-pages.
>
> > What YUWD stand for?
>
> Young, User, Write, Dirty.  Young means that the page has not been aged
> by the VM.  User means that the page is accessible from userspace.
> Write means that userspace can write to the page, and Dirty means that
> the page has been written to.
>
> Since ARMs don't have support for 'young' and 'dirty' there's a translation
> from these four bits to emulate the effect of them; if a page is not
> 'young'
> we need to make any access fault.  If a page is not dirty, we need to make
> any write cause a fault.
>
> > The S and R bits are deprecated in VMSAv6. The following entries apply
> > to legacy systems only.
> >
> > 0 1 0 0b00 Read only Read only Privileged/User read only
> > 1 0 0 0b00 Read only No access Privileged read only
> > 1 1 0 0b00 - - RESERVED
> > 0 1 1 0bxx - - RESERVED
> > 1 0 1 0bxx - - RESERVED
> > 1 1 1 0bxx - - RESERVED
> >
> > And what does that x (don't care !?) mean ?
>
> x = don't care.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100412/8be04acc/attachment-0001.htm>