Confusion regarding ARMv5 MMU access permissions
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Apr 9 17:54:57 EDT 2010
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.
More information about the linux-arm-kernel
mailing list