Re: Allocate contiguous wired memory and obtain physical address
Re: Allocate contiguous wired memory and obtain physical address
- Subject: Re: Allocate contiguous wired memory and obtain physical address
- From: Terry Lambert <email@hidden>
- Date: Sun, 21 Dec 2008 15:38:02 -0800
On Dec 21, 2008, at 1:13 PM, "John D." <email@hidden> wrote:
On Sun, Dec 21, 2008 at 10:03 PM, Michael Smith <email@hidden> wrote:
If you were to explain *why* you want this allocation, it might be
easier to
help you.
I'm toying with how the IDT is handled in XNU. Basically I need to
setup my own IDT via LIDT. Apparently doing this via mp_rendezvous()
(this is for a project involving a patch to the kernel source) and
using the physical address returned by IOMallocContiguous won't help.
Obviously I'm copying the original IDT and saving its original
location to be restored eventually, albeit it's not required in this
scenario.
We have supported API for this. Take a look at the WINE sources for
example usage.
If you are trying to take over the normal system call vector, though,
that's not supported.
From a security perspective, if you wrote code that succeeded in
doing this, I would feel more or less obligated to break it by
declaring the kernel virtual address space off limits to modification
by Mach vm_* API.
I come from a Linux kernel development background and never
experienced this issue before, so I suppose I'm missing something
specific to XNU. Does the returned phys addr truly contain a fixed
address value?
Mike already indicated that kernel memory allocations are wired. There
is an API to get pageable kernel memory, but almost no one uses it (I
know of one caller). Wired allocations have fixed physical addresses,
by definition; that's what "wired" means.
I asked because kmem_alloc API functions exist for the same purpose
but they aren't even exported through com.apple.kernel.
Give it a break already.
There was no pun intended there, at all. I was simply stating a fact.
Since IOLib provides perfectly useful API for this, it's not a problem
this time.
I think Mike was merely pointing out that you'll be more likely to get
useful responses if you don't make back-handed jabs at architectural
decisions which have already been explained as to their purpose.
-- Terry
_______________________________________________
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