Memory Map Page Access
OS SWI Calls
» OS_DynamicArea
» OS_DynamicArea 0
» Memory Map Page Access
This value is used with the memory management SWIs to specify the access rights to the page, in terms of how much access privileged code (i.e. modules running in SVC mode) and unprivileged code (i.e. applications running in USR mode) has to the contents of the page.
| Value | Meaning |
|---|---|
| 0 | Full read+write+execute access in both privileged and unprivileged CPU modes |
| 1 | Read+write+execute in privileged modes, read+execute in unprivileged modes (Short descriptor page table format) 1 |
| Read+write+execute in privileged modes, read in unprivileged modes (Long descriptor page table format) 1 | |
| 2 | Read+write+execute in privileged modes, inaccessible in unprivileged modes |
| 3 | Read+execute in both privileged and unprivileged modes |
| 4-15 | System-dependent |
System-dependent access privileges
Starting with RISC OS 5.23, access privileges 4 and above are used to provide extra access privileges that provide greater control over memory protection than the original set of privileges provided. For example, on systems running on ARMv6 or later CPUs, there will be permissions available for marking areas of memory as readable/writable but non-executable.
Because the availability of these permissions is affected by the page table format that is in use by the OS and the architecture of the CPU that it is running on, it is not feasible to have a fixed mapping of access privilege numbers to permissions. Instead, software which wishes to use these additional permissions must determine their availability at runtime. Using OS_Memory 18 is the preferred method of doing this in released software. OS_Memory 17 is also available, but is perhaps most useful to determine which permissions are available during development.
Prior to RISC OS 5.23 access privileges 4 and above were reserved and must not be used.
Notes
Prior to RISC OS 3.5, access privilege 3 was the same as access privilege 2, i.e. read/write in privileged modes and inaccessible in unprivileged modes.
Using stricter permissions can help improve the stability and security of the system by limiting the amount of damage that malfunctioning or malicious software can cause. Therefore it’s recommended that all software uses the strictest possible access permissions wherever possible.
1 Historically RISC OS has used what’s now referred to as the “short descriptor” page table format, which allowed memory to be mapped as read/write in privileged modes and read-only in unprivileged modes. The newer “long descriptor” page table format lacks support for this confguration; the permissions for unprivileged modes must either match the privileged mode permissions or completely deny access. For RISC OS 5 systems which use the long descriptor format (i.e. those with RAM located above the 4GB physical barrier), access privilege 1 is actually mapped with the same permissions as access privilege 2, and an abort handler is used to provide emulation of usermode read access (via the same abort handler that powers OS_AbortTrap. OS_Memory 17 and OS_Memory 18 will act as if the memory has the permission listed in the above table, and if read accesses are being emulated then OS_Memory 24 will report the memory as being abortable.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.