C does not have sufficient low-level control over representation/memory layout for hardware interfacing; any such "control" you get is highly implementation dependent, and the same kernel code compiled with different C compilers will often not work.
My other post addressed this. ANSI C forbids field reordering.
You have no more and no less control over the runtime environment in C than you do in any other language. A conforming C compiler and runtime is perfectly free to use garbage collection and to terminate your program the first time you use "float x; return *(char*)".
No, C explicitly allows one to have no runtime, which is critical for some applications; this is the point I've been repeating over and over, and yet you don't seem to comprehend. You can't achieve this in other languages at the moment (except as I pointed out, C++, Ada), unless you roll your own.
Building a small compiler to support kernel development is negligible amounts of work compared to implementing the kernel, and there are plenty of compilers you could build on (Eiffel, Portable Object Compiler, tcc, Oberon, etc.).
So, where's yours then? You do kernel level work with "security and networking" features, so I'm sure it would benefit you to have all of your code verified correct. The truth is a portable language definition and implementation for any architecture is hard. C is already well-defined for low-level work, ubiquitous, and "good-enough" for most kernel-projects (except those seeking verification).
C and C++ do not fit your requirements at all; you only think they do because you confuse implementation-specific features that are not part of the language with the language itself. At best, you can argue that the specific language implemented by gcc with an Intel backend is good for your purposes, but the C programming language is, by itself, completely unsuitable for implementing kernels.
All the features of "C" you've pointed out have turned out to be either not features of the C standard at all, or completely incorrect. I'm not sure you're qualified to make such declarations. If you are, let's see some real evidence. Point me to the C standard features that preclude it's use for kernel development.
Here, I have criticized EROS (and by extension CapROS) for its microkernel design--relying on memory management hardware rather than language and runtime mechanisms in order to achieve correctness. Apparently, the EROS authors themselves realized this, which is why Coyotos uses a new programming language.
This is completely incorrect. You are conflating safety, correctness and security. Capabilities and correct use of MMU provide safety, and security guarantees (among mutually suspicious parties -- the point of EROS/CapROS). BitC will additionally provide correctness guarantees (the point of Coyotos).
I haven't said anything beyond that about EROS; that would be an entirely separate discussion. The fundamental problem I see with the EROS approach is that it is principle driven, rather than data driven. These people keep talking about "trust" and "security" without ever demonstrating measurable improvements in those areas under controlled conditions.
I seriously think you don't understand the capability security model. Let me help:
ANSI C strictly forbids field reordering. In-memory layout is precisely as defined in the struct to the nearest byte (bit fields are known to be non-portable and thus unusable).
memory access through cast pointers
Defined by the host architecture. I'm not sure what C has to do with this. It merely defines a portable syntax for pointer dereference.
memory allocation and management
Portable malloc/free API. Not sure what you're point is here.
memory mapped I/O
Not part of the C standard.
Which only goes to show that all your objections to how one can't use anything other than C are groundless.
I never said you can't use anything other than C. Are you even reading what I write? I merely said that C is the currently probably the best candidate, particularly for a microkernel implementation.
We could now start debating whether the methodology underlying the development of EROS and Coyotos ("principle based") is acceptable and whether the authors are actually properly testing their claims or just handwaving. We could also discuss whether even the principles that the authors of those systems pursue hold water or are misguided. But those are separate discussions
Which is not true on any modern C implementation. You can't depend on code layout at all, stack layout varies between compilers (and optimization settings), as does struct layout.
ANSI C strictly forbids field reordering.
No careful programmer does something like write() directly from a struct, and expect it to behave properly in any reasonable fashion.
You certainly can, but it's stupid because a) it's brittle and can break with future changes to the struct, and b) it's pottentially nonportable across architectures with endianness differences.
Kernels just need to be written in languages that allow direct control over in-memory representation for code that needs it.
By definition, a microkernel is composed almost exclusively by such code. Where is the advantage of using a higher-level language then?
In "real" real-time code, you use the idiom of pre-allocating everything you need before you hit the critical path. This idiom holds for both GC'ed languages (in which you turn off the GC in the critical path), and manually-managed languages.
Right, so you move from doing manual memory management, to doing manual GC management. How is this a big win exactly?
Soft real-time is good enough, and on modern CPUs, GC can do that.
Says who? It's not good enough for people who want to ensure their system can be used for hard realtime.
*Cough*.NET *Cough*. Seriously, there is no reason the language in question must be a high-level language usable for programmers. The language could be something like the.NET IL, which other languages could target.
You'd seriously recommend building an entire operating system, kernel included, on a single IL?
Region memory management has *very* real problems in constrained environments. It is lower overhead than GC in CPU time, but must necessarily keep garbage around a lot longer.
Depends on how you use it, certainly. The CPU time isn't what concerns me, the fact that it's explicit and predictable is what matters here.
Any decent Lisp compiler has low-level instructions (which could be blocked for user-level programs). You'd need some ASM for things like writing to I/O ports and special registers, but you need that for C as well.
Certainly. That's not the problem though; BitC itself has a Lisp/Scheme syntax, so it's not a limitation of the language, but the operational semantics. Lisp requires GC. Lisp cannot grant you sufficient control of the runtime. Thus, Lisp is unsuitable. If you modify Lisp to support these features, great, but then you no longer have Lisp, just something Lisp-like.
No, because then you are enforcing a particular language or runtime on an entire operating environment. This never has and never will work. To be useful a system must support arbitrary computational semantics. To be secure in such an environment it must support mutually suspicious co-operation.
However, the fact that the compiler can transform the program into something close to machine code doesn't change the fact that C programs, to begin with, are quite far away from machine code.
This also doesn't change the fact that C memory layouts translate directly byte-for-byte from source, to in-memory representation. All other higher-level languages discussed thus far explicitly allow the compilers to reorder fields as they see fit. This is unaccetable for code that interfaces with hardware. Thus, kernels must still be written in low-level languages that allow explicit control over representation.
I don't see how this reply answers my question. You claimed that technology needs to be developed to allow depending on language-level safety on existing machines.
No, this thread is about using these language implementations in a kernel. Some other thread offshoots also discuss using the entire language runtime as the basis for whole operating system runtime safety.
Language-level safety of the latter sort is a dead-end; you will never be able to sell to any appreciably sized market, a system that depends on a single language to run everything.
Also, "proof-carrying code" is a much stricter definition than what you seem to imply (google for it).
And notice, I never said we didn't have the technology, I said we don't have the implementations. Ada is proof enough that we can do better than C in terms of safety (although it too has a host of problems). Cyclone with region memory management is potentially even better than Ada in constrained environments. The technology, the knowledge exists, it just hasn't been brought together in a sufficiently low-language with which we can build microkernels. That's the drive behind BitC.
I'm not well-versed on JIts, but garbage collectors generally have better cache behavior than most manual memory managers. Compacting GC's tend to increase cache locality by compating live data together.
GC is non-predictable, so it's already out the window for any systems that hope to schedule anything close to realtime. Even "realtime garbage collection algorithms" don't yet have the numbers to justify their use in critical kernel paths. I've read that their mutator overheads are still above 50%, which is unacceptable in this domain.
Furthmore, many, if not most, modern microkernel designs have a "no kernel state" model, which means GC is pointless anyway as the kernel never frees memory. It allocates the only structures it will ever need at boot time, and those structures remain live until system shutdown. Avoiding state means that the kernel is not vulnerable to denial-of-resource attacks.
My argument in the parent post was questioning the grandparent's assertion that code-generation and other high-level techniques belong in the kernel, particularly a microkernel where the critical paths are often finely hand-tuned for performance. It's doubtful that a code-generator could do better, and these high-level features aren't even needed in a kernel since they introduce additional vulnerabilities to the system (like DOS for code-generation -- see Pebble OS for example). I don't doubt they're possible, and I don't doubt they could bring certain advantages, but just because we can, doesn't mean we should; there are many security (much larger TCB) and reliability (much more verification) concerns.
It's just that the OS kernel itself should be implemented in something a little higher level and a little safer than C, with the ability to drop down into unsafe operations when necessary and with some simple object oriented facilities.
No argument there (except object-oriented facilities which have little use in microkernels). Hence the reason for developing BitC and Coyotos.
Oberon seems like roughly the right level, or maybe a Java implementation like gcj.
I've love to see you fit garbage collection into a kernel environment. GC has made leaps and bounds in the past 20 years, but it's still infeasible for a high-performance operating system kernel (without hardware support that is). It's almost there though. Maybe another 10 years.
But tell you what: why don't you do some research about languages and OS implementations. Go look at languages like PL/1, Oberon, Algol, Modula-2, Modula-3, Ada, and Cedar/Mesa. Go look at operating systems like Alto, Multics, Oberon, Apple Lisa, and B5000.
Why don't you show me an operating system that actually has some modern features and we'll talk. Oberon is as close you can get, and it's unusable because it forces you to use Oberon exclusively.
Also, go look up the discussions on aliasing and pointers in C and all the problems that caused with optimization over the evolution of C since K&R. C is not, and has never been, a high performance language and often does not come even close to carefully written assembly language or well-optimized code for other languages.
Every programming language performance comparison in existence, with the exception of Fortran and assembly, says otherwise. But hey, who cares about evidence when you have an ideology?
And I'm well aware of the optimization limitations caused by aliasing. The fact is however, you will not find a language that meets the criteria I laid out in my other post, with the minimalism of C.
The other big problem with C is that many of its low-level features unnecessarily rely on implementation-specific features that aren't part of the standard.
Very few such features exist, they are well known, and they aren't used in operating system kernels. You are really grasping at straws here.
Come on, "early" is an irrelevant qualifier. The fact remains that languages like Modula-2, Modula-3, PL/1, Ada, Oberon, Lisp, Smalltalk, Cedar/Mesa, and Object Pascal have all been used for implementing operating systems, many of the commercial and widely used. The use of C for implementing operating systems is a fairly recent and mostly academic phenomenon.
Well, I've asked you repeatedly to point me to some evidence backing up your assertions. I've stated quite clearly that the above languages (save Ada and possibly Pascal) are unsuitable for microkernel implementations. I have yet to encounter a modern operating system, in other words, one with features post 1970s, that was written in the above languages. In case you didn't know, evidence trumps assertions.
So please, enlighten me. Here are the requirements for the language:
low-level control over representation/memory layout (hardware interfacing demands this)
control over runtime environment (you can't enforce a runtime environment on some kernel designs)
readily available compiler (preferably free as in beer, at the very least, since academic and free software work is, well, free)
The only candidates that fit that bill are, you guessed it:
C
C++
Ada
Pascal
Most programmers stay away from Pascal due to quirks which they can't stand. Ada also inherited a few of these quirks, but is a marked improvement.
And just for curiosity's sake, show me a kernel and/or operating system that doesn't depend upon special hardware written in:
Smalltalk (which came long after C FYI)
Modula-* (also came long after C)
Mesa/Cedar
Lisp
And FYI, I never stated C is the ultimate low-level language; it became widespread because of the spread of UNIX, and the ready availability of the C compiler on that platform. The momentum was furthered by the spread of free C compilers and the marked lack of alternative language implementations.
Also, it's strange that you should think developing in C is an academic phenomenon when it's clear from the literature that computer researchers try as far as possible to avoid C in favour of higher-level languages.
That's just the usual kinds of unfounded prejudices and misconceptions C fanboys have against all other languages and systems. It's really pointless to try to argue against them--there is a certain degree of stubbornness one simply can't overcome.
So I'm a C fanboy now? Actually, I detest C, but I do recognize the right tool for the job.
Well, it's pretty clear we aren't going to convince each other. For my work, I need a kernel into which I can hack new security and networking facilities. Sadly, the only realistic choices are C-based at this point. But between the available choices, the monolithic kernels look more attractive than the microkernels in every respect.
Well, good luck with that. Let us all know how you manage to implement security policies in a design that is completely incapable of enforcing them.
In the end, people like you will have to convince people like me that kernels like Mach and CapROS are worth the hassle, and you consistently fail to do that, in papers as well as discussions.
You know, you have yet to level a single point against any operating system that I support; you've mostly been ranting against the use of low-level languages in OS research. I'm not sure precisely how that translates into a conclusion that microkernels, and that CapROS in particular, aren't worthwhile. Really, you're only valid reason is that Linux is more developed (which is a valid reason). Without evidence to the contrary, which I have provided and you haven't, any conclusions otherwise are simply unfounded.
It's really not surprising that new operating system approaches have made so little headway over the last several decades.
It really is a shame that people get so stuck in their mindsets and are so convinced they're right that they fail to acknowledge evidence to the contrary, isn't it?
To be honest, I'm not sure I see the point in writing a microkernel in a high-level language. By definition, microkernels comprise the bare minimum of functionality required to expose a portable API. That means there will be very little if any code reuse, and all algorithms will be very low-level. The only benefits of languages at a higher level than C are type strictness and a bit more safety. At the moment, Ada fits that bill best as far as I can see. BitC will be much better.
Why not? What do you think people were using for writing operating systems before C and UNIX became popular with academics and a misguided generation of CS graduates?
You mean Lisp machines? That requires special hardware. All early operating systems were written in low-level languages, essentially assembler. C was among the first "portable assembly languages". Not the first, and perhaps not the best, but it clearly had some advantage if it won out over the rest.
The rest can be entirely done in a HLL other than C. Don't get me wrong: C was a neat hack and great fun on a PDP-11, but it has never been either a well-designed language or a high performance language.
C is barely a step up above assembler. You can't get higher performance than assembler. You can talk all you like about runtime profiling and optimizations, but the very nature of a microkernel means the code paths have already been highly tuned and minimized.
As for JITs and GC, both of them are bonuses from a performance point of view. A well-implemented JIT gives you cross-module optimization and inlining even in the presence of dynamic loading, something potentially quite useful in a kernel. And a GC is not only less error prone than manual storage management, it is also more efficient.
Perhaps you should re-read my post. From application-level programming perspectives, these features are well-motivated. From a microkernel perspective these features are ill-motivated, if feasible at all.
Additionally, any sort of runtime environment in the kernel itself, any sort of state even runtime modification, means the kernel is now vulnerable to denial-of-service attacks. The point of reliability, security and fault isolation in microkernel designs is to minimize the attack surface, not expand it.
But that's what I'm talking about. I mean, who is going to work on CapROS and who is going to bother using it? If I want capabilities, I can get them in Linux or BSD.
No, you really can't. I hope you're not talking about so-called "POSIX capabilities". Those are nothing like real capabilities. I suggest you re-read that literature you said you've read, because capabilities and capability operating systems are far more powerful than anything you can ever do in Linux or BSD. The best you can do is implement Plan 9-style private namespaces, which get you part of the way there.
No matter how badly C and C-based monolithic kernels may suck, the path towards better OSes is likely going to be incremental, starting from Linux or BSD: permitting the loading of modules written in other languages, adding a JIT, adding capabilities, etc.
Or starting with a microkernel, and implementing a Linux/BSD compatibility layer. Like the one that existed for KeyKOS way back in the 80s which provided binary-compatibility with UNIX operating systems. Like L4Linux. Like Xen. Even drivers can theoretically have a Linux compatibility cradle, and I believe this is the direction CapROS will pursue.
And if you believe in microkernels, then the path to making it happen is likely to be adding microkernel-like facilities to the Linux kernel.
You can't. The best you can do is something like real-time linux, which is really a microkernel running an instance of linux as a personality. Just like L4Linux. If you're going to run a microkernel, why not just program against a native API to take advantage of the flexibility and performance?
If microkernel designs are so great, then people will naturally start using those new microkernel facilities to add new drivers, file systems, etc.
Not "best we have" but "what we're stuck with". The "best we have" is using the optimizer technology developed for Lisp, Smalltalk, and now Java to make typechecks and rangechecks cheap, and allow programs to ditch the hardware-level "memory protection tax" that current CPUs are stuck with.
Without proof-carrying code or hardware support, ensuring memory protection at any granularity without implementing a full-blown virtual machine is impossible. There was a proposal a year or two ago outlining a low-level software segment protection scheme (for loading untrusted plugins, etc.), but the hardware isn't here yet (if it ever will be). Past architectures that had a protection bits per word were inferior either in performance or cost.
FMI/OS (based on VSTa) is tiny, performant and arguably quite well-designed.
I'm aware of VSTa. I was on the mailing list a few years ago in fact while I was still learning about operating systems. But the buffered message-passing design is a serious flaw in the system. It's not only a performance inhibitor, it also allows denial of resource attacks against the kernel. I do like it's Plan 9-semantics though; that's definitely the right/secure way to do UNIX.
All those techniques yield competitive performance to C in user space. Why do you think they wouldn't do so in kernel space?
I'm speaking from the perspective of a microkernel when I'm arguing this, so perhaps that illuminates things for you. A small implementation with critical code paths that fits nicely within L1 cache are essential for high performance. Can you honestly tell me with a straight face that JITC techniques, garbage collection, and other high-level features are competitive with C for producing such code? Point me to a high-level language you think is usable in a kernel, ie. with all or some of your desired feature set, then show me where it gives you direct low-level control over memory layout and data structure representation, and control over the runtime.
The only efforts I've seen in this regard are BitC, Nitro, and Cyclone (projects that actually have implementations that is). None of them are there yet.
I don't think any of those systems will ever result in a practical OS; they were/are research projects.
I suggest you read more about the history of EROS. It was initially designed as a direct reimplementation of KeyKOS, the first commercial timesharing operating system to support mutually suspicious clients. It's been used in ATMs and other mission-critical operations for decades. EROS has since improved on the KeyKOS design. There is absolutely no reason why CapROS could not become a practical system. There is nothing research-centric about EROS/CapROS except its unfinished nature.
I don't know what "technology" there needs to be. There are lots of native-code compilers that generate "safe" code. All that's required is some form of code-signing to guarantee that a program was compiled on such a compiler.
I'll say it once again, the only requirement for a language to be used in a kernel is direct control of low-level representation, and direct control of runtime environment. Many languages do not provide this.
Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk).
As a little addendum, I'll just submit that C, C++ and Ada are probably the only languages with free compilers that can be feasibly used to build a microkernel at this time.
Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk).
Agreed. I never said it had to be written in C or any other unsafe language. The only requirements are low-level control over representation, and strict control over the runtime.
Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few.
I doubt very much that this would be acceptable on modern hardware. Greatest performance enhancements on current archiectures due to caches. JITC, instruction rewriting, etc. are cache killers. As of this time, runtimes in the kernel are simply infeasible because the technology just isn't there yet. Certified compilers, proof-carrying code, etc. is possible, but the implementations aren't here yet (Coyotos is implementing BitC).
If you have some alternative design for a kernel or operating system which will mitigate the above issues, then why don't you be more specific and state it? Otherwise, we're just going to argue in circles since I have no idea what you're trying to demonstrate.
I doubt I would learn anything more from them than last time I read them...
Well, I think you should review the performance analyses, the identified bottlenecks and see how they apply to your ideas. There was a lot of good analysis done in EROS and in the L4 world.
Well, Coyotos at least looks like a far more worthwhile project than either Minix3 or EROS.
Well to each his own. CapROS/EROS can potentially deliver within two years but Coyotos is definitely further than that. I agree that it's a more promising architecture given it's being designed by the people who built EROS, but if you're looking for something more practical in the near future, look to CapROS.
Now, if that's the case, in what sense is a microkernel "more reliable"? Let's say that in 100 man years, my team can produce a fully functional and extensively tested monolithic kernel. If microkernels are harder to design and implement, in the same time, the same team may only implement some of the functionality and do less testing for an equivalent microkernel. So, the microkernel design is then actually inferior.
You misunderstand. The base primitives are hard to get right, not the entire system built on top of those primitives. Once the base primitives are well defined and tested, development is very rapid and the system overall is quite reliable and flexible; moreso than monolithic systems. The past 30 years of microkernel research has been investigating what truly are the smallest set of primitives one can live with, and how to efficiently implement them in hardware (well, that's a naive view, but it serves our purpose here).
OS researchers started with relatively monolothic microkernel designs (Mach), and then moved to progressively smaller and more principled designs as they discovered weaknesses in the other systems. We eventually ended up with L4, which has been argued as taking flexibility TOO far. The happy medium has mostly been struck in CapROS/EROS (and the next generation Coyotos will improve upon that even further). Whoever it was that predicted a few years ago that OS research was dead was only half right; it's not quite finished yet (see the Coyotos effort: a verified operating system implementation).
The only thing that monolithic kernels gain you is that they were fairly straighforward to user-level programmers, since it's almost like programming in a restricted application environment. So your kernel developer base is potentially larger. This is another reason why monolithic kernels are more popular today.
Microkernel kernels are harder to reason about because they are designed closer to the raw hardware, in the sense that the designers are counting raw cycles spent on a particular code path, and precisely how many cache misses are induced in a particular algorithm. You don't see this sort of anaylsis in monolithic kernels because it's nigh on impossible! There are simply too many variables to control.
So I meant it was hard to design and implement the primitives, ie. the microkernel kernel itself, but the services and applications above it are far more resilient and flexible as a result.
The microkernel is an ultra-small codebase that runs with dangerous priviledges; for example, Minix3 is only 4000 lines of code! With that 100 man years, you can probably test this microkernel code to hell and back again until you're extremely confident that there are little if any bugs in it (or you can verify it with automated proofs as the Coyotos effort is attempting). Try doing that with monolithic kernels!
Obviously there's still testing of the user-level services, but at least now you have confidence that you won't have reliability issues originating from supervisor mode. This is similar to the guarantees you get with static typing; I'm sure you'd agree that there is value in static typing in eliminating several classes of bugs. So it is with microkernels. With proper microkernel primitives, you can have further guarantees.
I agree with that definition of microkernel, but "Salamander" apparently does not.
I'm sure he agrees with that definition, but he's disagreeing with your assertions that the kernel as a managed virtual machine of some sort would be more practical and useful. While potentially an interesting direction for research, it does not at all seem feasible with current hardware. Well, current consumer hardware; high-end architectures have more exotic features which may make it possible.
Like it or not, hardware page-level protection is the best we have, and microkernels are thus far the best way of exploiting this widely deployed architecture. Fortunately, page-level protection really is good enough for every purpose we need. In particular see CapROS and Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security). I think you'll learn a lot from the papers written on EROS/CapROS.
Actually you'd need to check against every patent application and expired patent. Even then that is not the only possible source of "prior art".
Right, which is what I said.:-)
The other problems are that what is obvious dosn't tend to get written down and that the same thing might be possible to describe in different ways. (The latter is especially a problem with a dishonest applicant who is deliberatly trying to make something commonplace sound like a new idea.)
That is indeed another issue, since the patent must be "nonobvious to an expert in the field", and also a "useful advancement in the art". So not only does each patent ever recorded need to be consulted, but the patent can only be validated by consulting with other experts in the field, further increasing the difficulty of this process.
Which merely supports my position that patents (and possibly IP in general) are a waste of time and resources overall.
Slashdot Mirror
My other post addressed this. ANSI C forbids field reordering.
You have no more and no less control over the runtime environment in C than you do in any other language. A conforming C compiler and runtime is perfectly free to use garbage collection and to terminate your program the first time you use "float x; return *(char*)".
No, C explicitly allows one to have no runtime, which is critical for some applications; this is the point I've been repeating over and over, and yet you don't seem to comprehend. You can't achieve this in other languages at the moment (except as I pointed out, C++, Ada), unless you roll your own.
Building a small compiler to support kernel development is negligible amounts of work compared to implementing the kernel, and there are plenty of compilers you could build on (Eiffel, Portable Object Compiler, tcc, Oberon, etc.).
So, where's yours then? You do kernel level work with "security and networking" features, so I'm sure it would benefit you to have all of your code verified correct. The truth is a portable language definition and implementation for any architecture is hard. C is already well-defined for low-level work, ubiquitous, and "good-enough" for most kernel-projects (except those seeking verification).
C and C++ do not fit your requirements at all; you only think they do because you confuse implementation-specific features that are not part of the language with the language itself. At best, you can argue that the specific language implemented by gcc with an Intel backend is good for your purposes, but the C programming language is, by itself, completely unsuitable for implementing kernels.
All the features of "C" you've pointed out have turned out to be either not features of the C standard at all, or completely incorrect. I'm not sure you're qualified to make such declarations. If you are, let's see some real evidence. Point me to the C standard features that preclude it's use for kernel development.
Here, I have criticized EROS (and by extension CapROS) for its microkernel design--relying on memory management hardware rather than language and runtime mechanisms in order to achieve correctness. Apparently, the EROS authors themselves realized this, which is why Coyotos uses a new programming language.
This is completely incorrect. You are conflating safety, correctness and security. Capabilities and correct use of MMU provide safety, and security guarantees (among mutually suspicious parties -- the point of EROS/CapROS). BitC will additionally provide correctness guarantees (the point of Coyotos).
I haven't said anything beyond that about EROS; that would be an entirely separate discussion. The fundamental problem I see with the EROS approach is that it is principle driven, rather than data driven. These people keep talking about "trust" and "security" without ever demonstrating measurable improvements in those areas under controlled conditions.
I seriously think you don't understand the capability security model. Let me help:
Structure layout
ANSI C strictly forbids field reordering. In-memory layout is precisely as defined in the struct to the nearest byte (bit fields are known to be non-portable and thus unusable).
memory access through cast pointers
Defined by the host architecture. I'm not sure what C has to do with this. It merely defines a portable syntax for pointer dereference.
memory allocation and management
Portable malloc/free API. Not sure what you're point is here.
memory mapped I/O
Not part of the C standard.
Which only goes to show that all your objections to how one can't use anything other than C are groundless.
I never said you can't use anything other than C. Are you even reading what I write? I merely said that C is the currently probably the best candidate, particularly for a microkernel implementation.
We could now start debating whether the methodology underlying the development of EROS and Coyotos ("principle based") is acceptable and whether the authors are actually properly testing their claims or just handwaving. We could also discuss whether even the principles that the authors of those systems pursue hold water or are misguided. But those are separate discussions
What claims? Security claims? Performance claims?
Which is not true on any modern C implementation. You can't depend on code layout at all, stack layout varies between compilers (and optimization settings), as does struct layout.
ANSI C strictly forbids field reordering.
No careful programmer does something like write() directly from a struct, and expect it to behave properly in any reasonable fashion.
You certainly can, but it's stupid because a) it's brittle and can break with future changes to the struct, and b) it's pottentially nonportable across architectures with endianness differences.
Kernels just need to be written in languages that allow direct control over in-memory representation for code that needs it.
By definition, a microkernel is composed almost exclusively by such code. Where is the advantage of using a higher-level language then?
In "real" real-time code, you use the idiom of pre-allocating everything you need before you hit the critical path. This idiom holds for both GC'ed languages (in which you turn off the GC in the critical path), and manually-managed languages.
Right, so you move from doing manual memory management, to doing manual GC management. How is this a big win exactly?
Soft real-time is good enough, and on modern CPUs, GC can do that.
Says who? It's not good enough for people who want to ensure their system can be used for hard realtime.
*Cough* .NET *Cough*. Seriously, there is no reason the language in question must be a high-level language usable for programmers. The language could be something like the .NET IL, which other languages could target.
You'd seriously recommend building an entire operating system, kernel included, on a single IL?
Region memory management has *very* real problems in constrained environments. It is lower overhead than GC in CPU time, but must necessarily keep garbage around a lot longer.
Depends on how you use it, certainly. The CPU time isn't what concerns me, the fact that it's explicit and predictable is what matters here.
Any decent Lisp compiler has low-level instructions (which could be blocked for user-level programs). You'd need some ASM for things like writing to I/O ports and special registers, but you need that for C as well.
Certainly. That's not the problem though; BitC itself has a Lisp/Scheme syntax, so it's not a limitation of the language, but the operational semantics. Lisp requires GC. Lisp cannot grant you sufficient control of the runtime. Thus, Lisp is unsuitable. If you modify Lisp to support these features, great, but then you no longer have Lisp, just something Lisp-like.
No, because then you are enforcing a particular language or runtime on an entire operating environment. This never has and never will work. To be useful a system must support arbitrary computational semantics. To be secure in such an environment it must support mutually suspicious co-operation.
However, the fact that the compiler can transform the program into something close to machine code doesn't change the fact that C programs, to begin with, are quite far away from machine code.
This also doesn't change the fact that C memory layouts translate directly byte-for-byte from source, to in-memory representation. All other higher-level languages discussed thus far explicitly allow the compilers to reorder fields as they see fit. This is unaccetable for code that interfaces with hardware. Thus, kernels must still be written in low-level languages that allow explicit control over representation.
I'm all for type safety, memory safety, and all sorts of other high-level goodies, but until the three criteria are met by another candidate, C remains the choice to beat.
Define "proof-carrying code".
Proof Carrying Code.
Most Lisp compilers will (unless they are told not to) generate safe code.
We're not just talking about memory or type safety. If that was all that was needed, I'd just recommend Ada.
I don't see how this reply answers my question. You claimed that technology needs to be developed to allow depending on language-level safety on existing machines.
No, this thread is about using these language implementations in a kernel. Some other thread offshoots also discuss using the entire language runtime as the basis for whole operating system runtime safety.
Language-level safety of the latter sort is a dead-end; you will never be able to sell to any appreciably sized market, a system that depends on a single language to run everything.
Also, "proof-carrying code" is a much stricter definition than what you seem to imply (google for it).
And notice, I never said we didn't have the technology, I said we don't have the implementations. Ada is proof enough that we can do better than C in terms of safety (although it too has a host of problems). Cyclone with region memory management is potentially even better than Ada in constrained environments. The technology, the knowledge exists, it just hasn't been brought together in a sufficiently low-language with which we can build microkernels. That's the drive behind BitC.
I'm not well-versed on JIts, but garbage collectors generally have better cache behavior than most manual memory managers. Compacting GC's tend to increase cache locality by compating live data together.
GC is non-predictable, so it's already out the window for any systems that hope to schedule anything close to realtime. Even "realtime garbage collection algorithms" don't yet have the numbers to justify their use in critical kernel paths. I've read that their mutator overheads are still above 50%, which is unacceptable in this domain.
Furthmore, many, if not most, modern microkernel designs have a "no kernel state" model, which means GC is pointless anyway as the kernel never frees memory. It allocates the only structures it will ever need at boot time, and those structures remain live until system shutdown. Avoiding state means that the kernel is not vulnerable to denial-of-resource attacks.
My argument in the parent post was questioning the grandparent's assertion that code-generation and other high-level techniques belong in the kernel, particularly a microkernel where the critical paths are often finely hand-tuned for performance. It's doubtful that a code-generator could do better, and these high-level features aren't even needed in a kernel since they introduce additional vulnerabilities to the system (like DOS for code-generation -- see Pebble OS for example). I don't doubt they're possible, and I don't doubt they could bring certain advantages, but just because we can, doesn't mean we should; there are many security (much larger TCB) and reliability (much more verification) concerns.
It's just that the OS kernel itself should be implemented in something a little higher level and a little safer than C, with the ability to drop down into unsafe operations when necessary and with some simple object oriented facilities.
No argument there (except object-oriented facilities which have little use in microkernels). Hence the reason for developing BitC and Coyotos.
Oberon seems like roughly the right level, or maybe a Java implementation like gcj.
I've love to see you fit garbage collection into a kernel environment. GC has made leaps and bounds in the past 20 years, but it's still infeasible for a high-performance operating system kernel (without hardware support that is). It's almost there though. Maybe another 10 years.
But tell you what: why don't you do some research about languages and OS implementations. Go look at languages like PL/1, Oberon, Algol, Modula-2, Modula-3, Ada, and Cedar/Mesa. Go look at operating systems like Alto, Multics, Oberon, Apple Lisa, and B5000.
Why don't you show me an operating system that actually has some modern features and we'll talk. Oberon is as close you can get, and it's unusable because it forces you to use Oberon exclusively.
Also, go look up the discussions on aliasing and pointers in C and all the problems that caused with optimization over the evolution of C since K&R. C is not, and has never been, a high performance language and often does not come even close to carefully written assembly language or well-optimized code for other languages.
Every programming language performance comparison in existence, with the exception of Fortran and assembly, says otherwise. But hey, who cares about evidence when you have an ideology?
And I'm well aware of the optimization limitations caused by aliasing. The fact is however, you will not find a language that meets the criteria I laid out in my other post, with the minimalism of C.
The other big problem with C is that many of its low-level features unnecessarily rely on implementation-specific features that aren't part of the standard.
Very few such features exist, they are well known, and they aren't used in operating system kernels. You are really grasping at straws here.
Well, I've asked you repeatedly to point me to some evidence backing up your assertions. I've stated quite clearly that the above languages (save Ada and possibly Pascal) are unsuitable for microkernel implementations. I have yet to encounter a modern operating system, in other words, one with features post 1970s, that was written in the above languages. In case you didn't know, evidence trumps assertions.
So please, enlighten me. Here are the requirements for the language:
The only candidates that fit that bill are, you guessed it:
Most programmers stay away from Pascal due to quirks which they can't stand. Ada also inherited a few of these quirks, but is a marked improvement.
And just for curiosity's sake, show me a kernel and/or operating system that doesn't depend upon special hardware written in:
And FYI, I never stated C is the ultimate low-level language; it became widespread because of the spread of UNIX, and the ready availability of the C compiler on that platform. The momentum was furthered by the spread of free C compilers and the marked lack of alternative language implementations.
Also, it's strange that you should think developing in C is an academic phenomenon when it's clear from the literature that computer researchers try as far as possible to avoid C in favour of higher-level languages.
That's just the usual kinds of unfounded prejudices and misconceptions C fanboys have against all other languages and systems. It's really pointless to try to argue against them--there is a certain degree of stubbornness one simply can't overcome.
So I'm a C fanboy now? Actually, I detest C, but I do recognize the right tool for the job.
Well, it's pretty clear we aren't going to convince each other. For my work, I need a kernel into which I can hack new security and networking facilities. Sadly, the only realistic choices are C-based at this point. But between the available choices, the monolithic kernels look more attractive than the microkernels in every respect.
Well, good luck with that. Let us all know how you manage to implement security policies in a design that is completely incapable of enforcing them.
In the end, people like you will have to convince people like me that kernels like Mach and CapROS are worth the hassle, and you consistently fail to do that, in papers as well as discussions.
You know, you have yet to level a single point against any operating system that I support; you've mostly been ranting against the use of low-level languages in OS research. I'm not sure precisely how that translates into a conclusion that microkernels, and that CapROS in particular, aren't worthwhile. Really, you're only valid reason is that Linux is more developed (which is a valid reason). Without evidence to the contrary, which I have provided and you haven't, any conclusions otherwise are simply unfounded.
It's really not surprising that new operating system approaches have made so little headway over the last several decades.
It really is a shame that people get so stuck in their mindsets and are so convinced they're right that they fail to acknowledge evidence to the contrary, isn't it?
To be honest, I'm not sure I see the point in writing a microkernel in a high-level language. By definition, microkernels comprise the bare minimum of functionality required to expose a portable API. That means there will be very little if any code reuse, and all algorithms will be very low-level. The only benefits of languages at a higher level than C are type strictness and a bit more safety. At the moment, Ada fits that bill best as far as I can see. BitC will be much better.
:-)
Good luck with your project.
Instead of arguing ideology and theory, why don't you do some research and read some papers to back up your claims: Java Operating Systems: Design and Implementation.
Why not? What do you think people were using for writing operating systems before C and UNIX became popular with academics and a misguided generation of CS graduates?
You mean Lisp machines? That requires special hardware. All early operating systems were written in low-level languages, essentially assembler. C was among the first "portable assembly languages". Not the first, and perhaps not the best, but it clearly had some advantage if it won out over the rest.
The rest can be entirely done in a HLL other than C. Don't get me wrong: C was a neat hack and great fun on a PDP-11, but it has never been either a well-designed language or a high performance language.
C is barely a step up above assembler. You can't get higher performance than assembler. You can talk all you like about runtime profiling and optimizations, but the very nature of a microkernel means the code paths have already been highly tuned and minimized.
As for JITs and GC, both of them are bonuses from a performance point of view. A well-implemented JIT gives you cross-module optimization and inlining even in the presence of dynamic loading, something potentially quite useful in a kernel. And a GC is not only less error prone than manual storage management, it is also more efficient.
Perhaps you should re-read my post. From application-level programming perspectives, these features are well-motivated. From a microkernel perspective these features are ill-motivated, if feasible at all.
Additionally, any sort of runtime environment in the kernel itself, any sort of state even runtime modification, means the kernel is now vulnerable to denial-of-service attacks. The point of reliability, security and fault isolation in microkernel designs is to minimize the attack surface, not expand it.
But that's what I'm talking about. I mean, who is going to work on CapROS and who is going to bother using it? If I want capabilities, I can get them in Linux or BSD.
No, you really can't. I hope you're not talking about so-called "POSIX capabilities". Those are nothing like real capabilities. I suggest you re-read that literature you said you've read, because capabilities and capability operating systems are far more powerful than anything you can ever do in Linux or BSD. The best you can do is implement Plan 9-style private namespaces, which get you part of the way there.
No matter how badly C and C-based monolithic kernels may suck, the path towards better OSes is likely going to be incremental, starting from Linux or BSD: permitting the loading of modules written in other languages, adding a JIT, adding capabilities, etc.
Or starting with a microkernel, and implementing a Linux/BSD compatibility layer. Like the one that existed for KeyKOS way back in the 80s which provided binary-compatibility with UNIX operating systems. Like L4Linux. Like Xen. Even drivers can theoretically have a Linux compatibility cradle, and I believe this is the direction CapROS will pursue.
And if you believe in microkernels, then the path to making it happen is likely to be adding microkernel-like facilities to the Linux kernel.
You can't. The best you can do is something like real-time linux, which is really a microkernel running an instance of linux as a personality. Just like L4Linux. If you're going to run a microkernel, why not just program against a native API to take advantage of the flexibility and performance?
If microkernel designs are so great, then people will naturally start using those new microkernel facilities to add new drivers, file systems, etc.
I guess we'll see.
Does anyone else read CapROS as CrapOS?
;-)
Perhaps that should be the motto huh? "All OSes are crap. CapROS: less crappy than the rest."
Not "best we have" but "what we're stuck with". The "best we have" is using the optimizer technology developed for Lisp, Smalltalk, and now Java to make typechecks and rangechecks cheap, and allow programs to ditch the hardware-level "memory protection tax" that current CPUs are stuck with.
Without proof-carrying code or hardware support, ensuring memory protection at any granularity without implementing a full-blown virtual machine is impossible. There was a proposal a year or two ago outlining a low-level software segment protection scheme (for loading untrusted plugins, etc.), but the hardware isn't here yet (if it ever will be). Past architectures that had a protection bits per word were inferior either in performance or cost.
A virtual machine in the kernel is simply infeasible at this point, so I'd rephrase it as "best we currently have at such a low-price point" if you want to be pedantic. See my other post on what is being done with better languages.
FMI/OS (based on VSTa) is tiny, performant and arguably quite well-designed.
I'm aware of VSTa. I was on the mailing list a few years ago in fact while I was still learning about operating systems. But the buffered message-passing design is a serious flaw in the system. It's not only a performance inhibitor, it also allows denial of resource attacks against the kernel. I do like it's Plan 9-semantics though; that's definitely the right/secure way to do UNIX.
All those techniques yield competitive performance to C in user space. Why do you think they wouldn't do so in kernel space?
I'm speaking from the perspective of a microkernel when I'm arguing this, so perhaps that illuminates things for you. A small implementation with critical code paths that fits nicely within L1 cache are essential for high performance. Can you honestly tell me with a straight face that JITC techniques, garbage collection, and other high-level features are competitive with C for producing such code? Point me to a high-level language you think is usable in a kernel, ie. with all or some of your desired feature set, then show me where it gives you direct low-level control over memory layout and data structure representation, and control over the runtime.
The only efforts I've seen in this regard are BitC, Nitro, and Cyclone (projects that actually have implementations that is). None of them are there yet.
I don't think any of those systems will ever result in a practical OS; they were/are research projects.
I suggest you read more about the history of EROS. It was initially designed as a direct reimplementation of KeyKOS, the first commercial timesharing operating system to support mutually suspicious clients. It's been used in ATMs and other mission-critical operations for decades. EROS has since improved on the KeyKOS design. There is absolutely no reason why CapROS could not become a practical system. There is nothing research-centric about EROS/CapROS except its unfinished nature.
I don't know what "technology" there needs to be. There are lots of native-code compilers that generate "safe" code. All that's required is some form of code-signing to guarantee that a program was compiled on such a compiler.
I'll say it once again, the only requirement for a language to be used in a kernel is direct control of low-level representation, and direct control of runtime environment. Many languages do not provide this.
Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk).
As a little addendum, I'll just submit that C, C++ and Ada are probably the only languages with free compilers that can be feasibly used to build a microkernel at this time.
Man operating systems have been implemented in languages with more safety and fault isolation features than C (languages like PL1, Modula-3, Oberon, ObjectPascal, Cedar/Mesa, Algol, Ada, Lisp, and Smalltalk).
Agreed. I never said it had to be written in C or any other unsafe language. The only requirements are low-level control over representation, and strict control over the runtime.
Fault isolation within a single address space can be provided in software via safe languages, safe runtimes, sandboxing via instruction rewriting, and certified compilers, to name just a few.
I doubt very much that this would be acceptable on modern hardware. Greatest performance enhancements on current archiectures due to caches. JITC, instruction rewriting, etc. are cache killers. As of this time, runtimes in the kernel are simply infeasible because the technology just isn't there yet. Certified compilers, proof-carrying code, etc. is possible, but the implementations aren't here yet (Coyotos is implementing BitC).
If you have some alternative design for a kernel or operating system which will mitigate the above issues, then why don't you be more specific and state it? Otherwise, we're just going to argue in circles since I have no idea what you're trying to demonstrate.
I doubt I would learn anything more from them than last time I read them...
Well, I think you should review the performance analyses, the identified bottlenecks and see how they apply to your ideas. There was a lot of good analysis done in EROS and in the L4 world.
Well, Coyotos at least looks like a far more worthwhile project than either Minix3 or EROS.
Well to each his own. CapROS/EROS can potentially deliver within two years but Coyotos is definitely further than that. I agree that it's a more promising architecture given it's being designed by the people who built EROS, but if you're looking for something more practical in the near future, look to CapROS.
Now, if that's the case, in what sense is a microkernel "more reliable"? Let's say that in 100 man years, my team can produce a fully functional and extensively tested monolithic kernel. If microkernels are harder to design and implement, in the same time, the same team may only implement some of the functionality and do less testing for an equivalent microkernel. So, the microkernel design is then actually inferior.
You misunderstand. The base primitives are hard to get right, not the entire system built on top of those primitives. Once the base primitives are well defined and tested, development is very rapid and the system overall is quite reliable and flexible; moreso than monolithic systems. The past 30 years of microkernel research has been investigating what truly are the smallest set of primitives one can live with, and how to efficiently implement them in hardware (well, that's a naive view, but it serves our purpose here).
OS researchers started with relatively monolothic microkernel designs (Mach), and then moved to progressively smaller and more principled designs as they discovered weaknesses in the other systems. We eventually ended up with L4, which has been argued as taking flexibility TOO far. The happy medium has mostly been struck in CapROS/EROS (and the next generation Coyotos will improve upon that even further). Whoever it was that predicted a few years ago that OS research was dead was only half right; it's not quite finished yet (see the Coyotos effort: a verified operating system implementation).
The only thing that monolithic kernels gain you is that they were fairly straighforward to user-level programmers, since it's almost like programming in a restricted application environment. So your kernel developer base is potentially larger. This is another reason why monolithic kernels are more popular today.
Microkernel kernels are harder to reason about because they are designed closer to the raw hardware, in the sense that the designers are counting raw cycles spent on a particular code path, and precisely how many cache misses are induced in a particular algorithm. You don't see this sort of anaylsis in monolithic kernels because it's nigh on impossible! There are simply too many variables to control.
So I meant it was hard to design and implement the primitives, ie. the microkernel kernel itself, but the services and applications above it are far more resilient and flexible as a result.
The microkernel is an ultra-small codebase that runs with dangerous priviledges; for example, Minix3 is only 4000 lines of code! With that 100 man years, you can probably test this microkernel code to hell and back again until you're extremely confident that there are little if any bugs in it (or you can verify it with automated proofs as the Coyotos effort is attempting). Try doing that with monolithic kernels!
Obviously there's still testing of the user-level services, but at least now you have confidence that you won't have reliability issues originating from supervisor mode. This is similar to the guarantees you get with static typing; I'm sure you'd agree that there is value in static typing in eliminating several classes of bugs. So it is with microkernels. With proper microkernel primitives, you can have further guarantees.
I agree with that definition of microkernel, but "Salamander" apparently does not.
I'm sure he agrees with that definition, but he's disagreeing with your assertions that the kernel as a managed virtual machine of some sort would be more practical and useful. While potentially an interesting direction for research, it does not at all seem feasible with current hardware. Well, current consumer hardware; high-end architectures have more exotic features which may make it possible.
Like it or not, hardware page-level protection is the best we have, and microkernels are thus far the best way of exploiting this widely deployed architecture. Fortunately, page-level protection really is good enough for every purpose we need. In particular see CapROS and Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security). I think you'll learn a lot from the papers written on EROS/CapROS.
Actually you'd need to check against every patent application and expired patent. Even then that is not the only possible source of "prior art".
:-)
Right, which is what I said.
The other problems are that what is obvious dosn't tend to get written down and that the same thing might be possible to describe in different ways. (The latter is especially a problem with a dishonest applicant who is deliberatly trying to make something commonplace sound like a new idea.)
That is indeed another issue, since the patent must be "nonobvious to an expert in the field", and also a "useful advancement in the art". So not only does each patent ever recorded need to be consulted, but the patent can only be validated by consulting with other experts in the field, further increasing the difficulty of this process.
Which merely supports my position that patents (and possibly IP in general) are a waste of time and resources overall.