[I added a subject to the thread.]
At 2020-01-10T15:19:17+0300, abdi mahmud haji wrote:
hey guys I'm abdurahman and i have same question for you i have been studying microkernel for a little well now specially seL4 and i have done almost every tutorials in sel4 -tutorials and i have a crazy idea ,that is i when try to build a 'shell or prompt' on the seL4 mircokernel but i don't have any idea how to do or where to start . does any one have a suggestion for me
Hi Abdurahman,
The short answer is that you'll need to write or obtain a lot more infrastructural components before you can put anything resembling a Unix shell, or even an old-fashioned MS-DOS prompt, on top of the seL4 microkernel.
Here's a longer answer.
If you study operating systems or systems programming you will become aware of a great many services that are provided by a fully-fledged "OS personality" (like Unix or Windows NT), and the standard libraries of a programming language.
There is a great deal just to the C standard library as set forth by the ISO, and the Austin Group's POSIX standard is even thicker. Most of what is described there, like string-handling functions, dynamic memory allocation, date and time services, signal handlers, Unix processes, terminal I/O, filesystems, and much more is stuff that doesn't need to be in a microkernel.
What does not need to be in a microkernel does not go into seL4; as Jochen Liedtke, lead developer of the L3 and L4 microkernels, put it:
"A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality."[1]
The Linux, *BSD (including Darwin), and Windows NT kernels are all immensely bloated by this standard. The Mach microkernel, an attempt to do a leaner Unix kernel in the 4.3BSD era (the 1980s), did not follow it and harmed the reputation of microkernels for a generation. (Admittedly, Liedtke articulated his principle in 1995, in retrospect at the relative failure of Mach.)
When you also consider the fact that seL4 is designed for system implementers who want strong isolation guarantees between programs hosted on it, anything like a traditional Unix shell starts to make less sense. A Unix command like "ps" might not make very much sense, as the mere presence of other processes on the system should not be observable except by explicit intention. seL4 lacks even the concept of a "root" or administrative user who gets to override the privacy protections of unprivileged users. Instead seL4 has only specific capabilities; a superuser who has all capabilities is a tempting target for attacks on security, so seL4 does not implement one.
That said, for design and debugging purposes, as well as educational purposes to help people learn the system, a shell-like monitor for seL4 might be a good idea. It's something I'd like to see. But it would probably not feel very familiar to a Unix (or even Windows CMD.EXE) user.
Gernot Heiser, one of the lead designers of seL4, has told me that the kernel's API is designed to be virtualizable, in the sense that you could design and configure a system that interposed a layer between the seL4 kernel and threads running on it; this layer could perform logging operations, do event reporting through a serial device, or even supply a shell/monitor that permitted interactive exploration of the system. My instinct is that such a thing would be highly useful for learning one's way around the system and designing applications for it. Then, when you went to production builds, the interposed layer could be disabled, reducing the system's memory footprint, improving performance, and restoring information-flow properties that monitoring is, in part, designed to violate.
It takes some time to get "microkernel brain", as I call it. Keep asking questions--this community is happy to try answering them.
Regards, Branden