OSDev.org

I need some clarification on the exokernel concept ... I really do not
understand the difference between a hardware abstraction layer
and and an exokernel ... It appears to be one and the same thing ....

Also if it provides access to the bare hardware ... how to implement
security ... or Is it that exokernel is simply an extended hardware
abstraction layer ... I have read the wiki and many other articles
please do help ..

An exokernel presents an interface that avoids abstraction. A HAL, IIUC, tries to present an interface that deliberately abstracts in order to allow the code above it to be ignorant of hardware particulars.

To a HAL I might say, "map physical address P to virtual address V with flags F". I don't have to know how this gets done; the HAL translates that directive into whatever the MMU requires.

To an exokernel I would say, "set entry E of the page table to X" or "insert X into the TLB", where X is specifically whatever the hardware requires. I still have to have knowledge of the hardware.

And this is also where the security comes in. The exokernel provides secure multiplexing by forcing me to ask it to perform hardware operations. The kernel can then check to ensure that my request does not break security (in this example, that I'm not mapping someone else's pages without permission).

Andy S Tanenbaum ... In the initial chapter does present the
notion of OS as an 'extended machine' ....

Exokernel then IMHO beats the purpose of an OS . If the application
programmer is to program the hardware directly ... One may argue
that different librararies can provide the required abstraction ...


But creating such libraries can cause a lot of headache ... For
some reason or the other it dosent seem to be very practical ....
The exokernel concept is pretty worthless afterall ......


I am a moron and may be totally incorrect .. plz advise as needed ...

SandeepMathew wrote:Andy S Tanenbaum ... In the initial chapter does present the notion of OS as an 'extended machine' ....

In an exokernel system, the kernel takes care of allowing multiple applications access to the same hardware securely, so that many applications can run simultaneously without stepping on each others' toes. So it *is* providing an additional service, it's just not abstraction.

SandeepMathew wrote:Exokernel then IMHO beats the purpose of an OS . If the application programmer is to program the hardware directly ... One may argue
that different librararies can provide the required abstraction ...

Yes, it is intended that most applications would use one of several generic libOSes, or change only a few parts. The point is that it gives you options.

SandeepMathew wrote:But creating such libraries can cause a lot of headache ... For some reason or the other it dosent seem to be very practical ....

Programming in user-space is *much* easier than programming in kernel-space.

SandeepMathew wrote:The exokernel concept is pretty worthless afterall ......

This is as though, after reading about microkernels, you would declare, "Well that's worthless: the microkernel doesn't provide crucial OS services like memory management and a file-system." It *does*, it just doesn't provide them where a monolithic kernel does. It is similar with an exokernel: the abstractions are moved from the kernel or privileged servers to applications, where they can be chosen or modified to suit an application's needs.

I have a question.

How exactly would you prevent concurrent access to devices that could be bad. For example one application just finished writing the read sector command to the hard drive when the next application gets it's turn to run and tries to send the write sector command. Do exokernels have some method of dealing with that or is it the OSlibs responsibility?

Part of the security in an exokernel is thread-safety. If I'd ask for several pages to be mapped in the same from different processes, I expect one to succeed and the other to fail because that piece of memory has already been granted to the other process.

An exokernel is not about directly asking the hardware, but about asking the kernel/driver to confirm your sanity before doing it for you. Instead of poking bytes to the IDE controller, you poke bytes to the driver, which then pokes the same bytes to the IDE controller should they make sense. Nevertheless, this level of nonabstraction is exxagerated even for an exokernel.

What really happens is that an exokernel exposes the primitives of a certain device. For the processor, those are the page tables and other constructs. For a harddisk, its a sector of data, not bytes appearing on a data port of the IDE controller.

Remember, an exokernel is about presenting a most thin layer over the hardware allowing the programmer to take advantage of the task ahead and hardware-level specifics. It is still an abstraction. An exokernel is still more than a HAL because it still checks on the programs correct behaviour and passing on corrective measures should one misbehave.

Summarized: the only essential difference with monolithic/modular/microkernels is that the abstractions that it provides are as minimal as possible to maintain security and stability of the system.

If I may,

IMHO, the point of the exokernel is that there is a separation between abstraction of hardware, and securely multiplexing it.

Your objective is then to secure the hardware without providing (hardly any) layer between the application and the hardware. This can be done by carefully focusing on what needs to be secure in order to guarantee safe multiplexing.

For my Operating System design, that means only that ports and memory need to be secured by this layer. Everything else can exist outside of it.

To secure memory, you simply need to check some control mechanism (capability or ACL) and then call the memory driver.

To secure the processor, you assume the memory is secure (code and stacks need to be registered as such, and so that's safe), so you let the processor driver handle it's own security (in a different program); it needs to account processor time and thread count.

I'm still not familiar with an efficient strategy to secure ports in a Capabilities fashion (drivers only have access to their own ports) though you could do it inefficiently through putting drivers in ring 3 and reflecting I/O access after checking.

All disk access is either via a port or page swap, now that you've revoked BIOS interrupts. You would of course want a secure file system, but again that's a different program. Likewise with video. With memory and ports secure, no BIOS interrupts, and assumed scheduler security, you can easily multiplex the screen.

So that's how I see the exokernel. It guarantees security between applications, and allows you to roll any memory manager, scheduler, video driver, or whatever separately. This is good because we don't have time to make everything perfect. If we can roll our own, we can mix and match the best and anyone can contribute a driver without compatibility issues. [/b]

Well .. Now things seems to be more clear .... The difference between
a HAL and exokernel is that 'exokernel securely multiplexes between
hardware resources ' ... It seems that exokernel is simply more than
an HAL ....
Thanks Guys!!

Well, no...

A HAL abstracts (hides implementation details to make it easier), while an exokernel multiplexes (allows multiple programs "fair" access to the system).

They're two entirely different efforts. The first is an attempt to escape complexity by putting makeup on it, while the second is an attempt to secure the provably insecure.

Welcome to the x86 platform.

Excuse me, but how are exokernel system provably insecure?

Under the assumption that drivers do not instruct the devices to do "wrong" DMA accesses, I can actually prove that my (exo)kernel design is guaranteed secure.

That does not mean that I can prove that its implementation is also bug-free.

Avarok and Combuster pretty much nailed it.

To paraphrase my work on DynatOS, an exokernel is a light abstraction of what a computer really has to offer, a finite processing resource. You have CPUs, RAM and I/O. *How* things are implemented is the part that is to be abstracted--securely.

In other words, think of an exokernel as a piece of software that turns the machine into a basic, "flat" and consistent resource that is guaranteed not to fail due to oversights that may occur within design of the actual operating system.

Guys .. I think i understood the concept ..., But why then the
exokernel systems are not so popular ...
Even microkernel systems are not so popular when compared
to Monolithic systems with support for loadable modules ... What
is the main reason for this ...? I guess only mach microkernel is
really popular ... What is the main reason ..? Is this something
similar to tcp/ip vs osi ..?

Sligthly off-topic still :- dont you think linux is becoming more windowish
day by day ....

Modular monolithic kernels are popular because they take the advantages of the modularity of microkernel systems and merge them with the speed advantages of running a single address space with kernel drivers.

Sligthly off-topic still :- dont you think linux is becoming more windowish
day by day .... Question Question Question

In what sense? At the end of the day the purpose of an operating system is to let the user run programs. Isn't that what both Linux and Windows do, at their core?

SandeepMathew wrote:Guys .. I think i understood the concept ..., But why then the
exokernel systems are not so popular ...

Probably because there are only a handful of them, and they are still very much proofs-of-concept rather than full-fledged systems. I think there are still a lot of unanswered questions around finding the best way to securely multiplex certain types of resources, such as CPU time.

Even microkernel systems are not so popular when compared
to Monolithic systems with support for loadable modules ... What
is the main reason for this ...?

The perception that microkernels are slower, and sheer momentum (monolithic systems that are popular today have roots in other monolithic systems from 20-30 years ago).

I guess only mach microkernel is
really popular ...

If you're talking about the OS X kernel, it's not a microkernel either. xnu includes Mach, but also a bunch of BSD code and kernel-mode drivers all mashed together.

Sligthly off-topic still :- dont you think linux is becoming more windowish day by day ....

Do you mean in terms of desktop environments and the UI design of apps? Windows is not worth emulating in those respects IMO...