Confusion regarding ARMv5 MMU access permissions
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.
Quoted 2 lines · Sasha Sirotkin
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 5 lines
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
Quoted 8 lines
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.
Quoted 11 lines
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
Quoted 1 line
from
armv3_set_pte_extmakes 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.
Quoted 1 line
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.
Quoted 11 lines
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 - - RESERVEDAnd what does that x (don't care !?) mean ?
x = don't care.
Quoted 4 lines · Russell King - ARM Linux
Quoted 2 lines · Sasha Sirotkin
I'm trying to figure out how ARMv5 MMU access permissions work in general and on Linux in particular.
Quoted 8 lines
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.
Quoted 2 lines
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.
Quoted 70 lines
Quoted 2 lines
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.
Quoted 5 lines
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 faultsQuoted 8 lines
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 - - RESERVEDAP[1:0] give you the binary bit combinations for the permission bits. For small pages, APX=0.
Quoted 11 lines
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/wQuoted 1 line
from
armv3_set_pte_extmakes 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.
Quoted 1 line
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.Quoted 10 lines
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
Quoted 4 lines
Quoted 1 line
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>