Difference between revisions of "Memory Management"
(PROOFREAD AND FACT CHECK PLZ. The previous comment wasn't helpful at all, being horribly confusing and possibly outright wrong.) |
|||
Line 170: | Line 170: | ||
ControlProcessMemory maps memory in the specified process, this is the only SVC which allows mapping executable memory. Format of the permissions field for memory mapping SVCs: bit0=R, bit1=W, bit2=X. Type6 sets the Addr0 memory permissions to the input permissions, for already mapped memory. Type is the MemoryOperation enum, without the memory-type/memory-region. ControlProcessMemory only supports type4, type5, and type6. ControlProcessMemory does not support using the current KProcess handle alias. | ControlProcessMemory maps memory in the specified process, this is the only SVC which allows mapping executable memory. Format of the permissions field for memory mapping SVCs: bit0=R, bit1=W, bit2=X. Type6 sets the Addr0 memory permissions to the input permissions, for already mapped memory. Type is the MemoryOperation enum, without the memory-type/memory-region. ControlProcessMemory only supports type4, type5, and type6. ControlProcessMemory does not support using the current KProcess handle alias. | ||
− | MapProcessMemory maps memory from | + | <code>'''MapProcessMemory'''(Handle process, u32 destAddr, u32 limit)</code> maps memory from the given process into the current process. First <code>min(limit, 0x3F00000)</code> bytes are mapped starting from <code>0x00100000</code> in the source process to <code>destAddr</code> in the current process. Then <code>min(limit - 0x7F00000, 0x6000000)</code> bytes (if more than 0) are mapped from <code>0x08000000</code> in the source process to <code>destAddr + 0x7F00000</code> in the current process. Another way to view this is that it is overlaying the two ranges <code>[0x0010_0000; 0x0400_0000]</code> and <code>[0x0800_0000; 0x0E00_0000]</code> from the source process onto <code>destAddr - 0x100000</code> in the current process, but only covering up to <code>limit + 0x100000</code> bytes. This is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory. |
Note that with the MAP MemoryOperation, the kernel will refuse to MAP memory for the specified addr1, when addr1 was already used with another MAP operation as addr1. The kernel also doesn't allow memory to be freed via the FREE MemoryOperation, when other virtual-memory is mapped to this same memory(when the MAP MemoryOperation was used with this memory with addr1). | Note that with the MAP MemoryOperation, the kernel will refuse to MAP memory for the specified addr1, when addr1 was already used with another MAP operation as addr1. The kernel also doesn't allow memory to be freed via the FREE MemoryOperation, when other virtual-memory is mapped to this same memory(when the MAP MemoryOperation was used with this memory with addr1). |
Revision as of 13:58, 6 August 2016
Types and structures
enum MemoryOperation
Memory operation | Id |
---|---|
FREE | 1 |
RESERVE | 2 |
COMMIT | 3 |
MAP | 4 |
UNMAP | 5 |
PROTECT | 6 |
REGION APP | 0x100 |
REGION SYSTEM | 0x200 |
REGION BASE | 0x300 |
LINEAR | 0x10000 |
The LINEAR memory-operation indicates that the mapped physical address is always MappedVAddr+0x0C000000, thus this memory can be used for hardware devices' DMA(such as the GPU). Addr0+size for this must be within the 0x14000000-0x1C000000 range when Addr0 is non-zero(Addr1 must be zero), Addr0 isn't actually used by svcControlMemory for mapping memory: Addr0 is not used by the kernel after doing address-range checks. The kernel determines what physical-address to use by allocating memory from FCRAM(about the same way as other memory), which is then used to determine the virtual-address.
8.0.0-18 added a new memory mapping(0x30000000-0x38000000) for LINEAR memory, this replaces the original mapping for newer titles. The kernel uses the new mapping when the process memory-region is BASE, or when the process kernel-release-version field is >=0x022c(2.44 / system-version 8.0.0-18).
The input mem-region value for svcControlMemory is only used(when non-zero) when the PID is value 1, for the FIRM ARM11 "loader" module.
enum MemoryPermission
Memory permission | Id |
---|---|
NONE | 0 |
R | 1 |
W | 2 |
RW | 3 |
X | 4 |
RX | 5 |
WX | 6 |
RWX | 7 |
DONTCARE | 0x10000000 |
enum MemoryState
Memory state flags | Value |
---|---|
FREE | 0 |
RESERVED | 1 |
IO | 2 |
STATIC | 3 |
CODE | 4 |
PRIVATE | 5 |
SHARED | 6 |
CONTINUOUS | 7 |
ALIASED | 8 |
ALIAS | 9 |
ALIAS CODE | 10 |
LOCKED | 11 |
struct MemoryInfo
Type | Field |
---|---|
u32 | Base process virtual address |
u32 | Size |
u32 | Permission |
enum MemoryState | State |
enum PageFlags
Page flags | Bit |
---|---|
LOCKED | 0 |
CHANGED | 1 |
struct PageInfo
Type | Field |
---|---|
PageFlags (u32) | Flags |
Memory Mapping
ControlMemory and MapMemoryBlock can be used to map memory pages, these two SVCs only support mapping execute-never R/W pages. The input permissions parameter for these SVCs must therefore be <=3, where value zero is used when un-mapping memory. Furthermore it appears that only regular heap pages can be mirrored (it won't work for TLS, stack, .data, .text, for example).
Bitmask 0xF00 for ControlMemory parameter MemoryType is the memory-type, when this is zero the memory-type is loaded from the kernel flags stored in the exheader ARM11 kernel descriptors, for the process using the SVC.
ControlMemory parameter MemoryType with value 0x10003 is used for mapping the GSP heap. The low 8-bits are the type: 1 is for un-mapping memory, 3 for mapping memory. Type4 is used to mirror the RW memory at Addr1, to Addr0. Type4 will return an error if Addr1 is located in read-only memory. Addr1 is not used for type1 and type3.
The ARM11 kernel does not allow processes to create shared memory blocks via svcCreateMemoryBlock, when the process memorytype (from the kernel flags stored in the exheader kernel descriptor) is the application memorytype, and when addr=0. When the memorytype is not the application memorytype and addr=0, the kernel allocates new memory for the calling process and turns it into a shared memory block. When addr is non-zero, it must be located in memory which is already mapped. Furthermore, it appears that only regular heap pages (allocated using svcControlMemory op=COMMIT) are accepted as valid addrs.
ControlProcessMemory maps memory in the specified process, this is the only SVC which allows mapping executable memory. Format of the permissions field for memory mapping SVCs: bit0=R, bit1=W, bit2=X. Type6 sets the Addr0 memory permissions to the input permissions, for already mapped memory. Type is the MemoryOperation enum, without the memory-type/memory-region. ControlProcessMemory only supports type4, type5, and type6. ControlProcessMemory does not support using the current KProcess handle alias.
MapProcessMemory(Handle process, u32 destAddr, u32 limit)
maps memory from the given process into the current process. First min(limit, 0x3F00000)
bytes are mapped starting from 0x00100000
in the source process to destAddr
in the current process. Then min(limit - 0x7F00000, 0x6000000)
bytes (if more than 0) are mapped from 0x08000000
in the source process to destAddr + 0x7F00000
in the current process. Another way to view this is that it is overlaying the two ranges [0x0010_0000; 0x0400_0000]
and [0x0800_0000; 0x0E00_0000]
from the source process onto destAddr - 0x100000
in the current process, but only covering up to limit + 0x100000
bytes. This is used by RO Services to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.
Note that with the MAP MemoryOperation, the kernel will refuse to MAP memory for the specified addr1, when addr1 was already used with another MAP operation as addr1. The kernel also doesn't allow memory to be freed via the FREE MemoryOperation, when other virtual-memory is mapped to this same memory(when the MAP MemoryOperation was used with this memory with addr1).
How The Kernel Allocates And Tracks Memory
MemoryBlockHeader
Size: 0xC-bytes(?) pre-v11.0, 0x18-bytes starting with v11.0.
Offset | Type | Description |
---|---|---|
0x0 | u32 | Size in pages |
0x4 | MemoryBlockHeader* | Next |
0x8 | MemoryBlockHeader* | Prev |
0xC | MemoryBlockHeader* | Pointer to the current memchunk. Added with v11.0? |
0x10 | u32 | Nonce, doesn't seem to be read at all except during MAC calculation. Added with v11.0. Used with the new heap security feature. A kernel state field is copied to this field before calculating the MAC. Once done, that kernel state field is subtracted by the value of the calculated MAC stored below. Since this kernel state field is initially 0x0, this field for the FCRAM APPLICATION+0 MemoryBlockHeader during kernel boot is set to 0x0. |
0x14 | u32 | MAC calculated over rest of struct. Added with v11.0. Used with the new heap security feature. |
RegionDescriptor
Size: 0x10-bytes pre-11.0.0-X, 0x20-bytes starting with 11.0.0-X.
Offset | Type | Description |
---|---|---|
0x0 | MemoryBlockHeader* | |
0x4 | MemoryBlockHeader* | |
0x8 | u32 | Region start |
0xC | u32 | Region size |
0x10 | 0x10-byte block. | This is the "key" used with the kernel heap MAC implemented with 11.0.0-X. |
FCRAM Region Descriptor
Size: 0x50-bytes pre-11.0.0-X, 0x80-bytes starting with 11.0.0-X.
X = RegionDescriptor_size*3.
Offset | Type | Description |
---|---|---|
0x0 | RegionDescriptor | RegionDescriptor for app memory |
RegionDescriptor_size*1 | RegionDescriptor | RegionDescriptor for sys memory |
RegionDescriptor_size*2 | RegionDescriptor | RegionDescriptor for base memory |
X + 0x0 | u32 | Ptr to start of FCRAM region descriptor |
X + 0x4 | u32 | FCRAM start |
X + 0x8 | u32 | FCRAM size in pages |
X + 0xC | u32 | Base memory start in FCRAM |
X + 0x10 | u32 | Count of physical FCRAM used by the kernel, in bytes. (used by svcGetSystemInfo) |
X + 0x14 | u32 | ? |
X + 0x18 | KThread* | Thread operating on region data |
X + 0x1C | s16 | Error info for thread listed above |
X + 0x1E | u16 | Alignment |