<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">&lt;<a href="mailto:linux@arm.linux.org.uk">linux@arm.linux.org.uk</a>&gt;</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>
&gt; I&#39;m trying to figure out how ARMv5 MMU access permissions work in<br>
&gt; general and on Linux in particular.<br>
<br>
If you&#39;re interested in ARMv5, only look at the ARMv5 documentation;<br>
don&#39;t get confused by the later stuff because that&#39;s totally different.<br>
<br>
&gt; Table B4-1 MMU access permissions (from the ARM Architecture Reference<br>
&gt; 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&#39;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&#39;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>
&gt; 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>
&gt; How should I read ARM MMU access permissions table:<br>
&gt;<br>
&gt; S R APXa AP[1:0] Privileged permissions User permissions Description<br>
&gt; 0 0  0       0b00     No access No access All accesses generate<br>
&gt; permission faults<br>
&gt; x x  0       0b01     Read/write No access Privileged access only<br>
&gt; x x  0       0b10     Read/write Read only Writes in User mode generate<br>
&gt; permission faults<br>
&gt; x x  0       0b11     Read/write Read/write Full access<br>
&gt; 0 0 1        0b00     - - RESERVED<br>
&gt; 0 0 1        0b01     Read only No access Privileged read only<br>
&gt; 0 0 1        0b10     Read only Read only Privileged/User read only<br>
&gt; 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>
&gt; and trying to correlate it with<br>
&gt; * Permission translation:<br>
&gt; *  YUWD   AP    SVC    User<br>
&gt; *  0xxx  0x00    no acc    no acc<br>
&gt; *  100x  0x00    r/o    no acc<br>
&gt; *  10x0  0x00    r/o    no acc<br>
&gt; *  1011  0x55    r/w    no acc<br>
&gt; *  110x  0xaa    r/w    r/o<br>
&gt; *  11x0  0xaa    r/w    r/o<br>
&gt; *  1111  0xff    r/w    r/w<br>
&gt;<br>
&gt; 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>
&gt; 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&#39;t have support for &#39;young&#39; and &#39;dirty&#39; there&#39;s a translation<br>
from these four bits to emulate the effect of them; if a page is not &#39;young&#39;<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>
&gt; The S and R bits are deprecated in VMSAv6. The following entries apply<br>
&gt; to legacy systems only.<br>
&gt;<br>
&gt; 0 1 0 0b00 Read only Read only Privileged/User read only<br>
&gt; 1 0 0 0b00 Read only No access Privileged read only<br>
&gt; 1 1 0 0b00 - - RESERVED<br>
&gt; 0 1 1 0bxx - - RESERVED<br>
&gt; 1 0 1 0bxx - - RESERVED<br>
&gt; 1 1 1 0bxx - - RESERVED<br>
&gt;<br>
&gt; And what does that x (don&#39;t care !?) mean ?<br>
<br>
x = don&#39;t care.<br>
</blockquote></div><br></div>