Memory Management - Revision history

Emufan4568: Update FCRAM memory management from latest TuxSH kernel idb

2024-03-30T23:29:21Z

Update FCRAM memory management from latest TuxSH kernel idb

← Older revision		Revision as of 03:29, 31 March 2024
Line 178:		Line 178:
	= How The Kernel Allocates And Tracks Memory =		= How The Kernel Allocates And Tracks Memory =

	== ~~MemoryBlockHeader~~ ==		FCRAM (128MiB for O3DS, or 256MiB for N3DS) is divided into three regions: APPLICATION, SYSTEM and BASE. A program is allowed to allocate memory in one of the three region. (For example games are always in the APPLICATION region). Inside one region, there are two kinds of memory that can be allocated: (regular) heap and linear heap.

			(Regular) heap is allocated starting from the end of the memory region, and growing down. They are mostly for application private use, and sometimes for software-based memory sharing (with other process using KSharedMemory, for example). They can be mapped to anywhere inside 0x08000000~0x10000000 virtual memory range upon application request. When the application requests for a block of heap, the block is not guaranteed continuous in FCRAM and the location is not specified either.

			Linear heap is allocated starting from the beginning of the memory region, and growing up. They are mostly for hardware-based memory sharing (with GPU, DMA etc.), but can also be used privately as well. They can be mapped to the linear heap virtual memory region (0x14000000+ or 0x30000000+, depending on game's kernel version). When the application requests for a linear heap block, the block is always continuous in FCRAM, and the difference between physical address and virtual address is always a constant. Therefore it gives virtual to physical address convertibility, which enables communication with other hardware.

			Each region in the kernel is managed by a dedicated KPageHeap object, which tracks free memory blocks. Each free block is represented with a KPageHeapBlock structure stored in FCRAM that stores the size of the free region and links to adjacent blocks. When a chunk of memory is allocated from the heap, the block is removed from the linked list and the region is cleared, erasing the header. On initialization a free block is inserted that covers the entire region.

			== KPageHeapBlock ==

	Size: 0xC-bytes(?) pre-v11.0, 0x18-bytes starting with v11.0.		Size: 0xC-bytes(?) pre-v11.0, 0x18-bytes starting with v11.0.
Line 193:		Line 201:
	\|-		\|-
	\| 0x4		\| 0x4
	\| ~~MemoryBlockHeader~~*		\| KPageHeapBlock*
	\| Next		\| Next
	\|-		\|-
	\| 0x8		\| 0x8
	\| ~~MemoryBlockHeader~~*		\| KPageHeapBlock*
	\| Prev		\| Prev
	\|-		\|-
	\| 0xC		\| 0xC
	\| ~~MemoryBlockHeader~~*		\| KPageHeapBlock*
	\| Pointer to the current memchunk. Added with v11.0?		\| Pointer to the current memchunk. Added with v11.0?
	\|-		\|-
	\| 0x10		\| 0x10
	\| u32		\| u32
	\| Nonce, doesn't seem to be read at all except during MAC calculation. Added with v11.0. Used with the new heap [[11.0.0-33\|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.		\| Nonce, doesn't seem to be read at all except during MAC calculation. Added with v11.0. Used with the new heap [[11.0.0-33\|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 KPageHeapBlock during kernel boot is set to 0x0.
	\|-		\|-
	\| 0x14		\| 0x14
Line 213:		Line 221:
	\|}		\|}

	== ~~RegionDescriptor~~ ==		== KPageHeap ==

	Size: 0x10-bytes pre-[[11.0.0-33\|11.0.0-X]], 0x20-bytes starting with [[11.0.0-33\|11.0.0-X]].		Size: 0x10-bytes pre-[[11.0.0-33\|11.0.0-X]], 0x20-bytes starting with [[11.0.0-33\|11.0.0-X]].
Line 224:		Line 232:
	\|-		\|-
	\| 0x0		\| 0x0
	\| ~~MemoryBlockHeader~~*		\| KPageHeapBlock*
	\| First		\| First
	\|-		\|-
	\| 0x4		\| 0x4
	\| ~~MemoryBlockHeader~~*		\| KPageHeapBlock*
	\| Last		\| Last
	\|-		\|-
Line 244:		Line 252:
	\|}		\|}

			The KPageHeap objects are owned by the KMemoryManager. This object acts as a light wrapper that abstracts allocations and freeing of memory from the heaps and handles page reference tracking.

	== ~~FCRAM Region Descriptor~~ ==		== KMemoryManager ==

	Size: 0x50-bytes pre-[[11.0.0-33\|11.0.0-X]], 0x80-bytes starting with [[11.0.0-33\|11.0.0-X]].		Size: 0x50-bytes pre-[[11.0.0-33\|11.0.0-X]], 0x80-bytes starting with [[11.0.0-33\|11.0.0-X]].

	X = ~~RegionDescriptor_size~~*3.		X = KPageHeap_size*3.

	{\| class="wikitable" border="1"		{\| class="wikitable" border="1"
Line 258:		Line 267:
	\|-		\|-
	\| 0x0		\| 0x0
	\| ~~RegionDescriptor~~		\| KPageHeap
	\| ~~RegionDescriptor~~ for app memory		\| KPageHeap for app memory
	\|-		\|-
	\| ~~RegionDescriptor_size~~*1		\| KPageHeap_size*1
	\| ~~RegionDescriptor~~		\| KPageHeap
	\| ~~RegionDescriptor~~ for sys memory		\| KPageHeap for sys memory
	\|-		\|-
	\| ~~RegionDescriptor_size~~*2		\| KPageHeap_size*2
	\| ~~RegionDescriptor~~		\| KPageHeap
	\| ~~RegionDescriptor~~ for base memory		\| KPageHeap for base memory
	\|-		\|-
	\| X + 0x0		\| X + 0x0
	\| ~~u32~~		\| KMemoryManager*
	\| Ptr to start of FCRAM region descriptor		\| Ptr to start of FCRAM region descriptor
	\|-		\|-
Line 282:		Line 291:
	\|-		\|-
	\| X + 0xC		\| X + 0xC
	\| u32		\| u32*
	\| ~~Base~~ memory ~~start in FCRAM~~		\| Pointer to FCRAM memory used for page reference tracking. Each u32 represents a page.
	\|-		\|-
	\| X + 0x10		\| X + 0x10
Line 294:		Line 303:
	\|-		\|-
	\| X + 0x18		\| X + 0x18
	\| KThread*		\| KLightMutex
	\| ~~Thread operating on region data~~		\| Mutex used for thread synchronization during memory (de)allocation from the heaps.
	\|-
	~~\| X + 0x1C~~
	~~\| s16~~
	~~\| Error info~~ for thread ~~listed above~~
	\|-
	~~\| X + 0x1E~~
	~~\| u16~~
	~~\| Alignment~~
	\|}		\|}


	== Kernel Region Descriptor ==		== Kernel Region Descriptor ==

Yellows8: /* Memory Mapping */

2016-12-07T03:09:43Z

Memory Mapping

← Older revision		Revision as of 06:09, 7 December 2016
Line 172:		Line 172:
	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.

	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). With the MAP MemoryOperation, the memory permissions for the original buffer are also set to no-access.

	<code>'''MapProcessMemory'''(Handle process, u32 destAddr, u32 limit)</code> maps memory from the given process into the current process. This memory is mapped with permissions RW-, regardless of the permissions for the memory under the specified 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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This system call is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.		<code>'''MapProcessMemory'''(Handle process, u32 destAddr, u32 limit)</code> maps memory from the given process into the current process. This memory is mapped with permissions RW-, regardless of the permissions for the memory under the specified 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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This system call is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.

Yellows8: /* Memory Mapping */

2016-12-01T23:17:31Z

Memory Mapping

← Older revision		Revision as of 02:17, 2 December 2016
Line 168:		Line 168:
	ControlMemory parameter MemoryType with value 0x10003 is used for mapping the GSP [[Memory_layout\|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.		ControlMemory parameter MemoryType with value 0x10003 is used for mapping the GSP [[Memory_layout\|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.		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. The addr(+size) must be >=0x00100000 and <0x14000000.

	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.

Yellows8: /* enum MemoryPermission */

2016-11-01T20:29:00Z

enum MemoryPermission

← Older revision		Revision as of 23:29, 1 November 2016
Line 56:		Line 56:
	\| 1		\| 1
	\|-		\|-
	\| W		\| W (Invalid, see below)
	\| 2		\| 2
	\|-		\|-
Line 77:		Line 77:
	\| 0x10000000		\| 0x10000000
	\|}		\|}

			Specifying write-permission without read-permission is invalid, it's handled the same way as if the RW bits were not set(ARM11-MPCore doesn't support write-only memory permissions).

	== enum MemoryState ==		== enum MemoryState ==

Yellows8: /* Memory Mapping */

2016-10-22T19:59:02Z

Memory Mapping

← Older revision		Revision as of 23:59, 22 October 2016
Line 172:		Line 172:
	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).

	<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This system call is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.		<code>'''MapProcessMemory'''(Handle process, u32 destAddr, u32 limit)</code> maps memory from the given process into the current process. This memory is mapped with permissions RW-, regardless of the permissions for the memory under the specified 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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This system call is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.

	= How The Kernel Allocates And Tracks Memory =		= How The Kernel Allocates And Tracks Memory =

Bond697 at 19:19, 12 October 2016

2016-10-12T17:19:19Z

← Older revision		Revision as of 21:19, 12 October 2016
Line 223:		Line 223:
	\| 0x0		\| 0x0
	\| MemoryBlockHeader*		\| MemoryBlockHeader*
	\|		\| First
	\|-		\|-
	\| 0x4		\| 0x4
	\| MemoryBlockHeader*		\| MemoryBlockHeader*
	\|		\| Last
	\|-		\|-
	\| 0x8		\| 0x8

Neobrain: /* Memory Mapping */

2016-08-06T12:21:08Z

Memory Mapping

← Older revision		Revision as of 16:21, 6 August 2016
Line 172:		Line 172:
	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).

	<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This ~~SVC~~ used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.		<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This system call is used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.

	= How The Kernel Allocates And Tracks Memory =		= How The Kernel Allocates And Tracks Memory =

Wwylele: /* Memory Mapping */ rearrange

2016-08-06T11:25:40Z

Memory Mapping: rearrange

← Older revision		Revision as of 15:25, 6 August 2016
Line 169:		Line 169:

	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.

			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).

	<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This SVC used by [[RO Services]] to map the program's code and heap into ro. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.		<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This SVC 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 =		= How The Kernel Allocates And Tracks Memory =

Yuriks: /* Memory Mapping */

2016-08-06T11:02:30Z

Memory Mapping

← Older revision		Revision as of 15:02, 6 August 2016
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.

	<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.		<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; destAddr + limit]</code> in the current process, truncating whatever part of the mapping that doesn't fit. This SVC 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).

Yuriks: /* Memory Mapping */

2016-08-06T10:58:55Z

Memory Mapping

← Older revision		Revision as of 14:58, 6 August 2016
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 a given process into the current process ~~using a virtual memory address range that is offset by 0x07f00000~~ from the ~~original address range~~. ~~In other words~~, the ~~memory range~~ [~~StartAddr,EndAddr~~] ~~is mapped to~~ [~~StartAddr+0x07f00000~~,~~EndAddr~~+~~0x07f00000]~~. This is used by [[RO Services]] to map ~~memory from 0x00100000 to 0x08000000~~. Memory mapped by MapProcessMemory is unmapped by UnmapProcessMemory.		<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).