My Kernel Service Model

[amd64pager]

I am currently developing a 64-bit OS in C++.
In my design,all kernel components(etc.device drivers) are inside kernel service classes.

Every service contains the following:
1)An access token that defines it's access level
2)A priority level
3)It's IRQ level(IRQL)
4)An entry and exit function
5)Virtual Address Descriptors(VADs) used by the memory manager
6)An handle table containing open kernel objects used by the service
7)A context block which is ignored by the scheduler but can be used in the start function of the service

Cooperative multitasking is used to run them.When one service exits by calling it's exit function,it is added to the back of the run queue and then all services in the run queue except the last one are run one by one.If a service with a higher priority and\or IRQL then the rest is present(very rarely this happens,as all of them are created with a priority level of 7 and IRQL of 0),it is executed first.

I would like any new ideas for it.

[JackScott]

As somebody who hasn't yet got to this point in my operating system development career, I can only pose the following question to you: Why have you chosen this specific design over any others? What are the benefits and pitfalls of your design?

[amd64pager]

The main reason for this design is security.

Even though the services run in kernel mode,none of them directly access everything.
There is a pointer pointing to the service info block which contains the access token.

Whenever it accesses something through the object manager(like \SysInfo\ACPI\Tables\MADT(data) or \HAL\ACPI\Tables.GetMADT[] (calling a function)),the access token is checked whether it allows access to that object.Normally a check to either of those objects(data or function) would give an security error in a device driver.

If you want I could post you the complete architecture

[gerryg400]

Why not push all these services out of the kernel and into ring3 so the processor can enforce your security for you?

[amd64pager]

That model is meant to encapsulate the kernel mode services(the memory manager is in there in fact).
This is the architecture of the Service Kernel(the HAL and Processor kernel provide basic services for the Service Kernel):
+-----------------+
| system threads |
+_______________+
|
\ /
\ /
+---------------------------------------------------------------------------------------------------------------------------------+
| System Service Call Dispatcher |
|----------------------------------------------------------------------------------------------------------------------------------|
| other services(like device drivers) |
|----------------------------------------------------------------------------------------------------------------------------------|
| Service Kernel Services( like the memory manager) |
|----------------------------------------------------------------------------------------------------------------------------------|
| Service Manager | Object Manager |HAL & Processor Kernel Object Mappings |
|----------------------------------------------------------------------------------------------------------------------------------|

(The kernel-mode services are not the same as user-mode services in my architecture.User-mode services are those started by the service control manager,
while kernel-mode services are services in the Service Kernel.)

[amd64pager]

Everything inside the kernel is implemented by an object.An object contains data and code and has to extend the Object class.So even the services itself exist as objects.
So whenever a service uses the object manager to access kernel objects(there is no other way),the access token which it holds is checked for whether it should allow the object to be written to or accessed.

So, if a service that has a device device driver(that was not an error;there are bus device drivers and device device drivers) tries to access \System\PageEntries\970\89\90(\System\PageEntries\PML4Index\PrimaryPageDirectoryIndex\PageTableIndex points to a page),it will surely fail(only the memory manager can access that).

And only some drivers are implemented there.The rest are user-mode processes which can define their own kernel-mode services in user-mode by using the UMDF(user-mode driver framework).The UMDF actually has part of itself in a kernel-mode service,which defines it's own stuff(like it's so called "indirectly-kernel-mode services).

[bluemoon]

Everything inside the kernel is implemented by an object.An object contains data and code and has to extend the Object class.So even the services itself exist as objects.
So whenever a service uses the object manager to access kernel objects(there is no other way),the access token which it holds is checked for whether it should allow the object to be written to or accessed.

No. There is another way. It may take a bit of engineering work to find out the layout of kernel structures, but once it's located, it can be accessed by ring0 drivers.

[amd64pager]

The object manager is a class(it's instantiated at runtime) ,and all that data is private,so you cannot use the hack you described,as the C++ compiler will give an error.

[bluemoon]

We have a miscommunication here. It has nothing to do with C++. Anything runs in ring0 can disable interrupt, access / remap the page tables, inspect every memory pages, and do a lot of funny things. The tricky part is how anyone knows where you store the interesting data. However, history tells us you can never avoid access by hide data - people will find them out.

[amd64pager]

Anyway,only a virus or worm developer would like to do that dirty hack

But I think we are going off topic.

I am currently developing a 64-bit OS in C++.
In my design,all kernel components(etc.device drivers) are inside kernel service classes.
...............
I would like any new ideas for it.

[bluemoon]

Anyway,only a virus or worm developer would like to do that dirty hack

You can say, the security is perfectly good when there is no virus or worm, but I think otherwise.

There is a pointer pointing to the service info block which contains the access token.

How about program bug? if the pointer is invalid, corrupted by buffer overruns, or points to something else, is there any protection to avoid accessing a totally different device?

I would like any new ideas for it.

You asked :p
It would be convenient to include signaling mechanism, or "inbox" to the service base class, so services can talk to each other (usb devices, or GUI service talk to video driver).

[gerryg400]

That model is meant to encapsulate the kernel mode services(the memory manager is in there in fact).
This is the architecture of the Service Kernel(the HAL and Processor kernel provide basic services for the Service Kernel):
+-----------------+
| system threads |
+_______________+
|
\ /
\ /
+---------------------------------------------------------------------------------------------------------------------------------+
| System Service Call Dispatcher |
|----------------------------------------------------------------------------------------------------------------------------------|
| other services(like device drivers) |
|----------------------------------------------------------------------------------------------------------------------------------|
| Service Kernel Services( like the memory manager) |
|----------------------------------------------------------------------------------------------------------------------------------|
| Service Manager | Object Manager |HAL & Processor Kernel Object Mappings |
|----------------------------------------------------------------------------------------------------------------------------------|

(The kernel-mode services are not the same as user-mode services in my architecture.User-mode services are those started by the service control manager,
while kernel-mode services are services in the Service Kernel.)

Just some random thoughts...

Objects need exception handling. Remember that an OS is not allowed a fatal error for OOM.

Objects need locking, probably a complex hierarchical read/write locking. As soon as there is more than one lock in your kernel you have the possibility of deadlock. You need a very robust locking design to support objects that are created and destroyed in response to asynchronous events.

If you support SMP or even sleeping in your kernel then you need some sort of reference counting. IMHO this is the most difficult aspect of object-oriented kernel design.

[amd64pager]

It would be convenient to include signaling mechanism, or "inbox" to the service base class, so services can talk to each other (usb devices, or GUI service talk to video driver).

Well,to signal or call other services,they use the object manager.
like if you want to leave a message ,it's like this: SeObjectManager.call("\ServiceManager\ISC.LeaveSignal[ServiceName,ServiceNo,SignalNo,ParamBlock")
Calling a function(ALPC(Advanced Local Procedure Call):SeObjectManager.call("\ServiceManager\ISC.Call[ServiceName,ServiceNo,FunctionNo,ParamBlock")
Leaving a deferred procedure call:SeObjectManager.call("\ServiceManager\ISC.DeferredCall[ServiceName,ServiceNo,FunctionNo,ParamBlock")
The messages are passed to the service when it is called.(it passes it in the parameter block).

Anyway,only a virus or worm developer would like to do that dirty hack

You can say, the security is perfectly good when there is no virus or worm, but I think otherwise.

There is a pointer pointing to the service info block which contains the access token.

How about program bug? if the pointer is invalid, corrupted by buffer overruns, or points to something else, is there any protection to avoid accessing a totally different device?

An advanced local procedure call or a deferred procedure call(services call other services by these) is done by the service manager,so always it changes that block.
If a service tries to jump or call those functions,the SRM(Security Reference Monitor) will kill it.

Objects need exception handling. Remember that an OS is not allowed a fatal error for OOM.

Objects need locking, probably a complex hierarchical read/write locking. As soon as there is more than one lock in your kernel you have the possibility of deadlock. You need a very robust locking design to support objects that are created and destroyed in response to asynchronous events.

If you support SMP or even sleeping in your kernel then you need some sort of reference counting. IMHO this is the most difficult aspect of object-oriented kernel design.

Spinlocks are implemented in the HAL.(Hardware abstraction layer)
Exception handling(called exception dispatching in my kernel) is implemented in the processor kernel.
Reference counting is implemented in the memory manager in part and the language support routines in part.
Efficient spinlocks are implemented in the service kernel base services
SMP is implemented in my kernel,so I thought of spinlocks at the start.

And objects can be active.(they can contain code and data)

[gerryg400]

Spinlocks are implemented in the HAL.(Hardware abstraction layer)

The actual locking is a few lines of trivial assembler. That's not the difficult part. The difficult part is fitting the object creation, locking, ref-counting and disposal together and having that all work in an multi-core system. Expect about 30% of a microkernel to be devoted to that.

Exception handling(called exception dispatching in my kernel) is implemented in the processor kernel.

By exceptions, I meant the object meaning, not the Intel meaning. So for example an object suddenly finds that a resource it needs has disappeared. Perhaps the user unplugged something, or a process died, and further suppose that the object has already started creating new objects and sending messages to them. The object perhaps also holds half a dozen spinlocks. How do you recover from that ?

Or perhaps an object needs to wait for a device for a ms or 2 and the object already holds some locks. Can it sleep ?

Reference counting is implemented in the memory manager in part and the language support routines in part.

Have you thought about how that will work scaleably in an SMP system ? Remember that your kernel will need to take references to objects frequently during it's execution, not just a object creation. And you will possibly need to be able to tell both the referring object and the referrer when that reference must be dropped. In extreme cases dropping a reference may require an IPI to ensure that a thread on another core drops the reference immediately. Think about a thread that calls _Exit while another thread is busy on another core creating more objects.

I've never really used C++ but I didn't think it had any SMP support in the language itself. I know very little about OO so forgive me if I've got it all wrong.

BTW, I'm not trying to put you off. Just trying to answer the hard questions up front.

[amd64pager]

You are correct a bit.