Re: Address range returned by malloc
Re: Address range returned by malloc
- Subject: Re: Address range returned by malloc
- From: Terry Lambert <email@hidden>
- Date: Sat, 04 Oct 2008 12:29:50 -0700
On Oct 4, 2008, at 12:10 PM, Greg <email@hidden> wrote:
When you call OSMalloc, IOMalloc, kern_os_malloc, or any of the
other mallocs in the kernel, I'm fairly sure I've read that they all
eventually call the same low-level malloc function in the kernel
(vm_page_alloc() I believe).
My question is what range is this address usually in? Is it
reasonable to assume, given the amount of memory used by the kernel
in RAM, that it will be less than the maximum value of a signed 32-
bit integer, even on 64-bit systems? Or is this not a safe
assumption at all?
Kernel virtual address space for a 32 bit kernel is limited to 32 bits.
Pointers are NOT signed values, so do not store the returned pointer
into a signed integer, or you may truncate it to 31 bits and overwrite/
access something in lower memory than your allocation actually
occurred when you go to use it. This would be Bad(tm).
If you need a generic pointer type, do not use an integer, use void *.
If you absolutely must use an integer type to do math (for example,
for a byte count rather than an element count in pointer math), then
the appropriate type is intptr_t (which is unsigned).
If this value is intended to be communicated to user space, consider
using a sized type capable of storing either a 32 or 64 bit pointer,
such as user_addr_t or uint64_t. This is normally discouraged, since
the likely reason for wanting to do it is because you intend to pass
the pointer back into the kernel later, and that would ne a gaping
security hole.
-- 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