Apple

It would be unwise to get the physical address for multiple reasons.

You don't want direct access anyway since if I remember correctly, after some version the Kernel is able to compress and encrypt the memory on the fly.

From: email@hidden
To: email@hidden
Subject: Re: Virtual memory map - some insight please !
Date: Thu, 29 Oct 2015 06:26:35 +0000
CC: email@hidden

I would also look into the "OSX and iOS Kernel Programming" book by Halversen and Clarke,
it has a chapter on memory management which you will probably find very helpful.

Also If not i'm not mistaken you want to use the GetPhysicalSegment to get the mapping between virtual memory and physical addresses

- hope this helps.

On 29/10/2015 5:07 pm, Rustam Muginov wrote:

Prokash,

you might want to check the WWDC 2008 session “Mac OS X 64-bit Kernel: Architecture and Kernel Extension Transition”.

You can find it at the https://developer.apple.com/videos page, in the “Archives” session. About one hour movie, but it 100% worth to watch if you want to get better understanding of subject.

IIRC, the separate address space was used with 32-bit Macs, kernel had 4GB address range and userspace had separate 4GB range, every boundary crossing was expensive.

After moving to 64-bit kernel (Mac OS X 10.7 is the first system having only 64-bit kernel) the situation is different - kernel using some address range and userspace using different address range, boundary crossing much cheaper.

If you are targeting modern OS X version, you should forget about 32-bit kernel, it is no longer used.

On Oct 28, 2015, at 5:56 PM, Prokash Sinha <email@hidden> wrote:

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

_______________________________________________ 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