Virtual memory map - some insight please !
Virtual memory map - some insight please !
- Subject: Virtual memory map - some insight please !
- From: Prokash Sinha <email@hidden>
- Date: Wed, 28 Oct 2015 17:56:35 -0700
Folks,
As I read from different books on osx internals, it seems like kernel has its own virtual memory space. At least in 32-bit, when address space was limited to 32bit, and 2GB(on Windows), 1GB in linux kernel space. So …
For example, in window, if we can guarantee that a kernel module is a top level module, we can access user memory from kernel module ( with address 0x80000000 or greater ). Though there are some basic address verification but there is hardly any need to have kernel side map using Memory descriptor list for user mode data, then mapped into system virtual space. So in essence, if the same process is executing is kernel mode context, user space address can be accessed. This is mainly because of kernel shared memory space.
In OSX, I heard for not sure if this mechanism(shared kernel address space) is there or not ?
Scenario, I’ve a kext that has an LAPIC range interrupt handler. When the handler gets invoked, the register context of the process from which the interrupt is coming is saved (definitely in kernel allocated address range).
Now when the interrupt handler executes, being kernel mode code, it must be in kernel virtual address space. Meaning that the translation of the instructions being executed must be going thru the kernel virtual address space !!!. If so, then addresses I’ve got using shared page from kernel virtual space should cause fault when accessing, if I don’t use copyinstr or its cousins.
Since the addresses are the process data section, and parameters to some function call at user-space, by using printf() I get all the details of the arguments. Whereas copyinstr does not give me those, actually the call fails.
So my question is that when I’m in the kext code, how does it manage to pull of the data that was pushed thru arguments to user-mode call.
Thanks in advance.
-Prokash
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden