But a system is not only APIs, how about threading, multi instances module, hardware resources conflict between modules, multiple modules implement same interface but running concurrently?
The core kernel does the scheduling. It maintains a structure for each application, and an application uses ghost functions to indirectly modify this structure. For example, a ghost function 'CreateThread' would tel the kernel to add a thread.
A module is in fact just a set of functions, so they can't really run concurrently. Else, I thought of a model similar to the famous COM for multiple ones to implement the same interface, so an interface would have an Interface ID (IID) and an implementation would have a Class ID (CLSID).
Modules inside the kernel get the address of system functions using the symbol tables. For example, with a call such as SymbolTable->GetFunction( "CreateThread" ). And the symbol table would have a constant address (or at least, it's address would be shown as being always the same using paging).
Hardware resources will be accessed, in my model, using a locking concept for those that can't be accessed concurrently.
As this is harmful, I am currently designing a model where devices would be treated as regular streams (e.g. have read/write functions etc...) and conccurent accesses would be scheduled by the kernel, so the applications would see it as an asynchronous access.
Nice idea! But it sounds so much like Windows NT architecture (except for ghost functions), am I wrong?
Not really, as Windows NT implements most things in userspace (using it's thousands of DLLs), while I implement them as modules that run in Ring 0. But this is just for fundamental functions. Modules are just parts of the system developped by me, users may not program modules (else, it would be a major security hole).
For interfaces, a class's methods are registered, and then their code is copied in a userspace page, so they can't harm much.
My design is also modular like your, but I sacrifice protection so application can access hardware directly. There are no kernel or userspace, everything run in ring 0, so it can become chaotic easily if I am not careful (the pain of not having protection)
You must have a very good reason to sacrify security at that point. But I hope that you have memory protection anyways (letting each process having it's own virtual address space, with no access to other process' memory, unless allowed by the kernel). But it could be hard for an application to write directly to the video card instead of just calling 'DrawLine'
A more familiar name would be dynamic linking?
Not really. Dynamic Linking just has symbols associated with a named library. The code for the functions is then copied to the aplication's virtual space and addresses are substituted.
Ghost Functions are not imported from any library, and are located somewhere in the kernel. When loading the application, the kernel maps the code of these functions (that are in kernel space) to the application's space (in user space) using paging.
When linking to a dynamic library, the linker leaves a note to the loader to load function X from library L and give the loading address. For ghost functions, these symbols are left undefined and the loader resolves them using the kernel's symbol table. It is more an alternative to software interruptions than real dynamic linking, the linker just does not do anything.
The reason for this is simply that it is way faster than dynamic linking (that requires loading a library) or software interruptions (that require traversing a table every call). It also allows the same system code to be loaded only once, while Windows loads the same DLL's several times and wastes memory.
@bluemoon : It's true that many things are more relevant to administration policies. For the boot, I didn't find a better solution.
From my understanding, his model is same as hybrid model of Windows NT.
No, I am not implementing the system functions as thousands of DLLs that decrease disk performance and size, I just use modules and a special form of linking.
IMO Windows NT is more MicroKernel than Modular, and I won't use as much messaging as it does.
Applications wont talk to the kernel? Please elaborate.
Applications don't really talk to the kernel using messaging or interruptions. Instead, they request functions from the kernel, which maps them to their address space. Applications don't talk to the kernel : they access it silently. This way, there can't be a virus that listens to them
Also, the functions from the kernel are in pages that are read-only, so they cannot corrupt it's code.
@piranha : Sorry, by 'don't access the kernel', I just meant that they can't modify it in a hramfl way. They just can read it, and not modify.
If your application is running in user mode (ring 3) then any call to the kernel that doesn't switch back to ring 0 would result in a GPF.
Isn't it possible for a ring 3 process to access a ring 0 page that is read-only ?
That takes me thinking... Would it be possible to have only one system call that switches to the execution of the kernel code ?
I am not using interruptions as they are not the most efficient solution.
But how can Windows applications call the drivers without elevation ? It doesn't look like they are making interruptions.
Any function can be injected from any source? How secure is that?
No, I just mean that any module can provide any function.
You think of your kernel as a set of functions, and if that were true your idea might work.
But really a kernel is a set of 'data' and the system calls are methods to manipulate the data. How will you ensure that the 'installed' system calls behave correctly with respect to the concurrency, re-entrancy and locking in your kernel ?
I will just have locking objects (mutexes, critical sections and all), And my Ghost Functions are not really system calls, they are just an alternative to the functions in Windows DLLs.
