0

When compiled to object code and then object files are linked together, statically or otherwise, they are placed in a [VAD][1], at least I know this for sure on modern Windows operating systems dated back to the late 2000s. My guess is that, and this is from the top of my head, but I assume a kernel library that is dynamically linked is placed in a TBL paged virtual address space with the main executable file and if dynamic linked libraries exist, like C's standard, they are linked together with main executable, but static, like [SDL][2], are not. So how is the executable accesses the protected memory, like drivers, etc. through the linked kernel library?

Hope my question isn't too confusing.

Basically, what I want to ask, in the shortest question, is:

How does a compiled/linked executable and accompanying libraries/APIs actually reach or interact with the OS API, kernel API, or otherwise system software necessary for hardware manipulation in run-time?

Giovanni Di Toro
  • 797
  • 1
  • 14
  • 34
  • See e.g. http://stackoverflow.com/questions/499188/how-is-the-system-call-in-linux-implemented , most conventional operating systems and CPUs works in a similar manner. – nos Jun 28 '13 at 20:23
  • That doesn't explain the process beyond it, such as device drivers and scheduling done between calls. All in all, it doesn't give me the answer I'm looking for. –  Jun 28 '13 at 20:49
  • then possibly you're looking for the fact that a CPU has several modes of operating, one mode which is privileged (which the OS runs in) that has access to all features of the CPU and the hardware and one which is unprivileged (which user processes runs in) and there's a simple way for a user process to call code running in the privileged mode and copy data back and forth between them. Or you're asking the basic construct and possibly intricate details of a modern kernel and CPU, which is a very large topic. – nos Jun 28 '13 at 21:02

1 Answers1

0

I can speak only for windows =) Firstly, thread has context, which include two stacks - kernel mode stack and usermode stack. CPU has commands - SYSENTER. These instruction use MSR registers IA32_SYSENTER_* which describes kernel mode entry point. When called, they switch current level to ring 0, switch stack to kernel-mode stack and call km entrypoint. On Windows this entry point called KiFastCallEntry. Basically these function call KiSystemService (), which save UM context into stack (KTRAP), copy arguments and call appropriate system service (usermode provide index into System Service Descriptor Table). After that KiSystemService set usermode context from KTRAP and call sysexit, which switch current privilege level to 3, switch stack to usermode and transfer control to caller (basically this is ntdll stubs). There are some difference with old xp and 2000 (they use int 2e trap from IDT) and AMD on x64.

This isn`t very precious description (e.g. there are several service descriptors tables, etc). You can read "Windows Inside" or something like http://shift32.wordpress.com/2011/10/14/inside-kisystemservice/ and http://wiki.osdev.org/SYSENTER#Compatability_across_Intel_and_AMD

Evgenii Gostiukhin
  • 970
  • 4
  • 8