I’ve a couple of questions.
From a user ap, when I execute a heap memory allocation routine, such as malloc() what is the underlying Native API that the system invokes ?
When i invoke a memory allocation native api (and i suppose i can invoke the same from both kernel and user mode) how does NT knows in which context is running? I explain, if I’m running in in user mode, i want my memory to be allocated in the user-mode accessible address space, while if i’m calling the function from kernel mode the buffer will be allocated in the address space ffffffff-80000000.
Is there a way to force the I7O manager to allocate its buffers (DriverObject, for instance) in the user-mode accessible address space?
Thanks
-Matt
>From a user ap, when I execute a heap memory allocation routine, such as
malloc() what is the underlying Native API that the system invokes ?
MSVCRT!malloc -> KERNEL32!HeapAlloc -> NTDLL!RtlAllocateHeap ->
NTDLL!NtAllocateVirtualMemory
The last one is the syscall. It always allocates an integral number of
pages.
When i invoke a memory allocation native api (and i suppose i can invoke
the same from both kernel and user mode) how does NT knows in which
context is running?
The thread object currently running on the CPU is pointed to by the PCR
field. Accessible by mov eax, fs:[0128h] to all kmode code.
The process is known from the thread.
the user-mode accessible address space, while if i’m calling the function
from kernel mode the buffer will be allocated in the address space
ffffffff-
80000000.
NtAllocateVirtualMemory always allocates user memory.
Is there a way to force the I7O manager to allocate its buffers
(DriverObject,
for instance) in the user-mode accessible address space?
No. This would open a huge hole in system stability.
The kernel is isolated from the user and must be isolated in any decent
OS. I don’t think that any stuff which will weaken this isolation must be
seriously considered.
NT (and Linux) is not a crappy OS like DOS or Win9x where the
system-important data structures are directly accessible to applications.
Yes, it hardens development sometimes, but it provides the stability which
is absent in DOS and Win9x.
Max
> From a user ap, when I execute a heap memory allocation routine, such as
malloc() what is the underlying Native API that the system invokes ?
Generally, when you allocate user memory with malloc, it doesn’t make any
system call. It just finds a memory block from the C run-time free memory
list (or splits a block). If there really is no memory available, a call to
VirtualAlloc (and underlying functions) happens to commit some more pages,
which does take a system call. Note that the behavior varies quite a lot
based on which version of the C run-time your using. There have been a
couple different allocator algorithms implemented in the C run-time. Some
versions have also just passed the call down to the Win32 API allocation
function HeapAlloc.
The REALLY ugly part is you may have a program linked with some version of
the C run-time, and does memory allocation in a certain way. You may also
then call a DLL (or COM object) that was linked differently. A common bug
is you want your DLL to return some memory block, and have the caller
delete it. Unless everybody is using the SAME allocator, bad things will
happen. The C run-time often seems to know it’s bad to deallocate a memory
block it didn’t allocate, so does nothing if it detects an attempt at this,
which causes a memory leak. Note that linking with the shared run-time (in
a DLL) vs. integrated linked in run-time causes this too. Also note that
hiding a bug by leaking memory is not exactly a good strategy for long
running apps.