OSDev.org

AFAIK, I see these available for me:

- Microkernel
- Exokernel
- Hypervisor / Virtualizing Kernel
- Nanokernel
or a simple bootloader / firmware that sets up virtual memory.

my goals for this kernel are:
- do as little as possible
- load multiple applications and services at start (load_kernel apps=socket,shell,framebuffer,testapp for ex)
- prevent race conditions to devices and access outside its memory space without permission
- give access as close as possible to the bare metal (without invading other process / data spaces or trying to access at the same time)

or should I just dodge any sort of style and use my own?

Regards

Your list does not contain the simplest choice: A monolithic kernel.

Everything other than a monolithic kernel will require some glue code between different components. Designing a good microkernel is much harder than designing a good monolithic kernel. Exo- and nanokernels are just extensions of the microkernel concept.

Korona wrote:Your list does not contain the simplest choice: A monolithic kernel.

Everything other than a monolithic kernel will require some glue code between different components. Designing a good microkernel is much harder than designing a good monolithic kernel. Exo- and nanokernels are just extensions of the microkernel concept.

Monotholic doesnt fulfill my requirements for 1) and 3). Difficulty is not an issue as I'm doing this for pleasure and mental stimulation. I like it hard.

Exokernels and nanokernels being an extension of the microkernel concept is incorrect since they do not do alot of the things the microkernel does in its definition.

Thanks for your reply and trying to help

Oh, I misread your first point. I thought you meant "I want to do as little as possible" and not "the kernel should be responsible for as little as possible" .

One point that should be considered is that performance decreases with increasing abstraction. In terms of performance monolithic > micro > exo, nano. If your kernel needs a context switch to invoke the scheduler or some memory manager, you'll need twice as many context switches as a traditional kernel.

The definition of {micro,exo,nano}kernel is somewhat arbitrary. Does a microkernel manage physical memory? Virtual memory? Scheduling? Different microkernels give different answers to those questions.

Monolithic kernel is a way to go. Easy to write and understand.
You can make it relatively reliable if you know how.
I personally think that everything else is just an abstraction. Drivers running in user mode (micro kernel) is something very relative, drivers running in kernel mode (monolithic kernel) is something very understandable and definitely more beneficial. You wouldn't have to use system calls at all, direct hardware access, etc...
What does running a driver actually mean to you? That is the relativity I am talking about. Drivers are very specific and I think they shouldn't be made into processes.

Hi,

gungomanj wrote:AFAIK, I see these available for me:

- Microkernel
- Exokernel
- Hypervisor / Virtualizing Kernel
- Nanokernel

First, split the choices into OS or virtual machine. While there's some similarities, they're used for extremely different things, provide very different features, etc.

If you chose virtual machine then there's other choices (hardware virtualisation or not, guest uses same architecture as host or not, paravirtualisation or full system emulation, etc).

If you chose OS; split the choices into "security or performance". Micro-kernels and nano-kernels are much better for security (due to barriers between drivers, etc and the kernel) but those barriers cost a little performance (and cost a little more development time).

If you chose security; then you're left with a choice between micro-kernel or nano-kernel. I'd define these as "things in user-space when there's some benefit to putting them in user-space (micro-kernel)" vs. "things in user-space whenever possible, even when there's no benefit at all (nano-kernel)".

If you chose performance; then you're left with a choice between exo-kernel and monolithic. The only real difference between exo-kernel and monolithic is how low-level the kernel API is (e.g. does kernel API provide higher level file IO where not much is needed in user-space libraries, or does kernel API provide lower level operations for reading/writing blocks from storage devices where user-space libraries need to do a lot more?).


Cheers,

Brendan

my goals for this kernel are:
- do as little as possible
- load multiple applications and services at start (load_kernel apps=socket,shell,framebuffer,testapp for ex)
- prevent race conditions to devices and access outside its memory space without permission
- give access as close as possible to the bare metal (without invading other process / data spaces or trying to access at the same time)

given requirements you cited, you are asking for microkernel design.

personally I like the hybrid kernel design, a highly modular kernel design not being frustrated with those modules being a part of kernel and run in the privileged mode. it's the best one for me and I even won't start to do anything else. monolithic design is a piece of fossilized dinosauric pooh, coprolitic design, this is for addicted religious unixoids, microkernels emmm yup they suck at performance I heard. did i pissed off enough people? no, then I'm gonna say, HV is just a waste of time and not even close to the "pleasure and mental stimulation".

Are you beginner / first-time kernel developer? If you are, I wouldn't recommend going for anything other than a monolithic kernel. OS development is not kind to those with sparse experience.

Looks like this is your first kernel, eh?
Go for monolithic kernel then, it's the simplest to get going first. A microkernel has too many moving parts. (I'm doing an exokernel and while you can finish the kernel proper rather fast there's million times more things you will need to create before it even boots)

I don't really understand the motivation for that monolithic kernels are "simpler" to write. I don't see an argument here and in my experience monolithic kernels are more difficult to make because of more complex kernels. Microkernels and such are easier because kernel space is simpler. The Kernel has a lot of limitations and you have to take special rules in account when programming complex system solutions in the kernel space that otherwise would fit much better in user space.

Do minimal in the kernel and as soon as you can get out in user space and feel the freedom.

The general advice is that monolithic is a "better" design for a first kernel (and likely a second and third) is as such because chances are you're either not going to be interested in how deep the systems design rabbit hole goes to reach the point of academic squabbling about kernel and userspace separation or you're going to scrap everything you do several times before you get really settled into design and implementation.

I've been at this for a decade and I'm on my fourth iteration with entirely different design goals, and it's something of a hybrid kernel. It's also more design documents than code, and I've been on this iteration for a couple years.

Hobby operating systems development in the "look-at-what-I-made it-displays-hello-world-from-a-floppy-disk" department is one thing. Hobby operating systems development in the "I have a design and clear goals here" department is a completely different monstrosity. We tend to get a lot more people who just stop after the former around here, and chances are by the time you've reached the latter, you can make your own informed decision as to what "style" of system you want to design and implement.

OSwhatever wrote:I don't really understand the motivation for that monolithic kernels are "simpler" to write.

It's easy - less moving parts to design and it's easier to redo them in one compilation unit if need be, rather than change full interfaces specfications for 25 to 50 separate components.

I should probably start another thread, but the more I think about the options that the OP has listed, the more confused I become. Could someone kindly shed light on some of the following questions. It would make the technical context more clear I think.

1. Can a microkernel perform unclean restart (after state corruption) of a driver, such as a filesystem, or even a network one, and not risk corruption of the state of user applications? Or is it meant to enable clean restarts only (i.e. deadlocked/livelocked/aged driver processes)?
2. Can a microkernel guarantee confidentiality of the data sent to different processes or drivers from the driver stack, without encrypting the data blocks and storing the keys outside of the normal storage, using some kind of TPM?
3. Can a microkernel guarantee the authenticity of the data without signing each data block that travels through its messaging system and storing the keys in a TPM?
4. Is the microkernel persistent security metadata for files implemented inside the filesystem driver, or inside some designated security module?
5. Can a microkernel schedule eagerly to decrease the servicing latency without risking to increase the number of context switches/TLB invalidations?
6. How similar or different are paravirtualization and microkernels that implement containers/namespaces/jails? Namely when considering that paravirtualization places higher-level drivers in separate address spaces for each guest, yet the physical space remains protected by the hypervisor, isn't that converging to microkernel architecture anyway, and what are the tradeoffs. I know that lower-level drivers used by virtualization are usually hosted in a single kernel, but I am not sure that this is fundamentally necessary and they cannot be distributed in different guests. In terms of feature set, assuming containers, filesystem snapshots, and microkernel driver processes, what additional options does paravirtualization (specifically) provide?
7. Can an exokernel provide simultaneously security and shared named resources on partitioned devices (memory, storage) without the use of filesystem driver or equivalent facility that is implemented in separate memory space or running in a different privilege level?
8. How similar or different are exokernels to virtualization using device passthrough? With device passthrough (such as SR-IOV), each guest is responsible for its own drivers that directly interact with the virtual device functions in the hardware, while the physical memory is protected by MMU and IOMMU. So, each kernel is similar to an exokernel process in a sense.
9. Can a single address space operating system be implemented securely without JIT-compiled/VM-running managed code? How does it compare performance-wise to microkernel designs? Can managed code be realtime without significant overhead - i.e. can garbage collection be efficient without being of the stop-the-world variety?

I will post my speculations here, in order to substantiate the inquiry.

simeonz wrote:Can a microkernel perform unclean restart (after state corruption) of a driver, such as a filesystem, or even a network one, and not risk corruption of the state of user applications? Or is it meant to enable clean restarts only (i.e. deadlocked/livelocked/aged driver processes)?

I believe, that in general, driver failure cannot be isolated, because the user processes consume data that originates in that driver and also rely on the driver to transfer information to storage or to a communication channel. This may not always be critical failure, but if the data was subsumed for the long-term in the client process, or was corrupted before reaching the media or cluster, continuing to use it and its derivatives hides additional security or integrity risks.

simeonz wrote:Can a microkernel guarantee confidentiality of the data sent to different processes or drivers from the driver stack, without encrypting the data blocks and storing the keys outside of the normal storage, using some kind of TPM?

If a driver is exploited or malicious, the processes can only hide information from it by encrypting it. This is not specific issue with microkernels, but is relevant to the qualities of microkernels. If encryption is used after all, the keys cannot be located in the primary storage which is behind a driver stack, but will have to use separate space, hopefully managed by simple, well-tested and trusted code. The cache and buffer management will probably have to be trusted as well to keep the performance acceptable. Note that filesystem drivers in some cases may operate by translation mechanism entirely, but in other cases they require to directly process the blocks, such as for deduplication and compression purposes. Many lower-level device drivers will be on the data path directly at all times.

simeonz wrote:Can a microkernel guarantee the authenticity of the data without signing each data block that travels through its messaging system and storing the keys in a TPM?

I understand that data can never be protected against losses due to denial of service from the driver, but at least the authenticity of information mediated by the driver can be proven with hashing and signing.

simeonz wrote:Is the microkernel persistent security metadata for files implemented inside the filesystem driver, or inside some designated security module?

For the same reasons as before, the security metadata managed in the filesystem driver is not safe. The filesystem drivers are generally complex, and can be network facing. It is exploitable code. And the user may desire to install third-party filesystems as well. Thus the security metadata should probably be managed by a separate process and interfaced to the filesystem as encrypted attribute. This is obviously taking things to their most extreme to obviate the academic constraints of each solution. I am not making assertions about the feasibility of these measures, and would like to hear your opinion.

simeonz wrote:Can a microkernel schedule eagerly to decrease the servicing latency without risking to increase the number of context switches/TLB invalidations?

The method used to decide how eagerly to schedule driver processes may be can be adaptive to the current and past workload to somehow mitigate the overhead of activation. I am not sure. I haven't thought about it enough. But I have noticed that this is a general problem for the efficiency in scheduling, when a system of processes operate in a pipeline.

simeonz wrote:How similar or different are paravirtualization and microkernels that implement containers/namespaces/jails? Namely when considering that paravirtualization places higher-level drivers in separate address spaces for each guest, yet the physical space remains protected by the hypervisor, isn't that converging to microkernel architecture anyway, and what are the tradeoffs. I know that lower-level drivers used by virtualization are usually hosted in a single kernel, but I am not sure that this is fundamentally necessary and they cannot be distributed in different guests. In terms of feature set, assuming containers, filesystem snapshots, and microkernel driver processes, what additional options does paravirtualization (specifically) provide?

It is apparent from the sentiment in my question, that I think microkernels and paravirtualization share goals and principles. I think that it is a matter of time before they converge. Unlike device emulation, paravirtualization is not fully OS agnostic, so it is already part of the OS architecture. It seems to be one of the two most active trends in virtualization, the other being device passthrough. In any case, I wonder what usability factors and technical tradeoffs will shape the final outcome of this convergence, if it indeed happens.

simeonz wrote:Can an exokernel provide simultaneously security and shared named resources on partitioned devices (memory, storage) without the use of filesystem driver or equivalent facility that is implemented in separate memory space or running in a different privilege level?

If you want to provide a namespace, on a partitioned, dynamically allocated device, I assume that you pretty much need something like a filesystem driver. And since the filesystem cannot use a shared unprotected global state, while enforcing security restrictions, it needs a separate privilege level or a separate process. But this is one of the complex components of the kernel, and the result will start to approximate a microkernel or monolithic kernel approach.

simeonz wrote:How similar or different are exokernels to virtualization using device passthrough? With device passthrough (such as SR-IOV), each guest is responsible for its own drivers that directly interact with the virtual device functions in the hardware, while the physical memory is protected by MMU and IOMMU. So, each kernel is similar to an exokernel process in a sense.

I think that exokernels and device passthrough virtualization are to each other, what microkernels and paravirtualization are to each other. Two converging fronts. Xen's unikernels also work on a similar tangent, although they are technically paravirtualization.

simeonz wrote:Can a single address space operating system be implemented securely without JIT-compiled/VM-running managed code? How does it compare performance-wise to microkernel designs? Can managed code be realtime without significant overhead - i.e. can garbage collection be efficient without being of the stop-the-world variety?

The other issues on this list make me consider software VM as a viable alternative. It ensures portability, flexible security inside a single address space, direct service/driver calls without overhead. I was very skeptical about it a month ago, and mainly due to the cost for handling real-time garbage collection and various memory inefficiencies. Hence the question - is it doable?

In general the answers to your questions heavily depend on the kernel/driver design. The answers vary depending on which microkernel you consider.

Carefully designed microkernels should be able to recover from driver crashes. However a microkernel alone is not sufficient to contain malicious drivers. You need an IOMMU (e.g. Intel V-d) to do that. Devices like XHCI are capable of DMA from/to arbitrary memory addresses and can thus corrupt even read-only kernel code.

Single-address space operating systems cannot be made safe without running trusted code (e.g. compiled from a managed language) only. At least this cannot be done without hardware assistance (e.g. something like segmentation + instrumentation, look up how Google's NaCl works).