<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Apr 10, 2010 at 12:54 AM, Russell King - ARM Linux <span dir="ltr"><<a href="mailto:linux@arm.linux.org.uk">linux@arm.linux.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, Apr 10, 2010 at 12:36:13AM +0300, Sasha Sirotkin wrote:<br>
> I'm trying to figure out how ARMv5 MMU access permissions work in<br>
> general and on Linux in particular.<br>
<br>
If you're interested in ARMv5, only look at the ARMv5 documentation;<br>
don't get confused by the later stuff because that's totally different.<br>
<br>
> Table B4-1 MMU access permissions (from the ARM Architecture Reference<br>
> Manual) does not make sense to me<br>
<br>
You really need to understand that table first.<br></blockquote><div>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.<br>
<br>One more question, if you don't mind. <br><br>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?<br>
<br>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?<br>
<br>Thanks a lot, your previous email was extremely helpful.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> How AP from the above table relate to AP[0:1] bits in the ARM page table ?<br>
<br>
This is covered in the ARMv5 ARM architecture reference manual.<br>
<br>
Small pages (4K) have four sets of permission bits, one for each 1K of<br>
the page. So the two bits are replicated across all entries to ensure<br>
that each 1K segment of a single 4K page has the same permissions.<br>
<br>
Extended pages (again 4K) have a different layout, where there is one<br>
single set of permission bits, and the freed bits are dedicated for<br>
other purposes - which includes adding an APX bit.<br>
<br>
> How should I read ARM MMU access permissions table:<br>
><br>
> S R APXa AP[1:0] Privileged permissions User permissions Description<br>
> 0 0 0 0b00 No access No access All accesses generate<br>
> permission faults<br>
> x x 0 0b01 Read/write No access Privileged access only<br>
> x x 0 0b10 Read/write Read only Writes in User mode generate<br>
> permission faults<br>
> x x 0 0b11 Read/write Read/write Full access<br>
> 0 0 1 0b00 - - RESERVED<br>
> 0 0 1 0b01 Read only No access Privileged read only<br>
> 0 0 1 0b10 Read only Read only Privileged/User read only<br>
> 0 0 1 0b11 - - RESERVED<br>
<br>
AP[1:0] give you the binary bit combinations for the permission bits.<br>
For small pages, APX=0.<br>
<br>
> and trying to correlate it with<br>
> * Permission translation:<br>
> * YUWD AP SVC User<br>
> * 0xxx 0x00 no acc no acc<br>
> * 100x 0x00 r/o no acc<br>
> * 10x0 0x00 r/o no acc<br>
> * 1011 0x55 r/w no acc<br>
> * 110x 0xaa r/w r/o<br>
> * 11x0 0xaa r/w r/o<br>
> * 1111 0xff r/w r/w<br>
><br>
> from armv3_set_pte_ext makes even less sense.<br>
<br>
AP refers to the access permissions bits in the small page case; and<br>
as you can see these are duplicated across the four 1K sub-pages.<br>
<br>
> What YUWD stand for?<br>
<br>
Young, User, Write, Dirty. Young means that the page has not been aged<br>
by the VM. User means that the page is accessible from userspace.<br>
Write means that userspace can write to the page, and Dirty means that<br>
the page has been written to.<br>
<br>
Since ARMs don't have support for 'young' and 'dirty' there's a translation<br>
from these four bits to emulate the effect of them; if a page is not 'young'<br>
we need to make any access fault. If a page is not dirty, we need to make<br>
any write cause a fault.<br>
<br>
> The S and R bits are deprecated in VMSAv6. The following entries apply<br>
> to legacy systems only.<br>
><br>
> 0 1 0 0b00 Read only Read only Privileged/User read only<br>
> 1 0 0 0b00 Read only No access Privileged read only<br>
> 1 1 0 0b00 - - RESERVED<br>
> 0 1 1 0bxx - - RESERVED<br>
> 1 0 1 0bxx - - RESERVED<br>
> 1 1 1 0bxx - - RESERVED<br>
><br>
> And what does that x (don't care !?) mean ?<br>
<br>
x = don't care.<br>
</blockquote></div><br></div>