OSDev.org

I think you are being to hard on both Oberon and Bernhard. No, Oberon is not like Unix, Linux, or Windows. Which is good. It offers a research platform into alternative ways of accomplishing the functions of an operating system. Remember also that an operating system is defined by far more than it's user interface.

Oberon is completely object-oriented, much like Java. It is written in the Oberon language, a simple object-oriented language similar to Pascal (the language and the OS were developed, in part, by Niklaus Wirth, the creator of Algol-W, Pascal and Modula). Think of 'Oberon the language' as a compiled version of Java. Type-safe, runtime binding, and fast.

The most "unusual" feature of 'Oberon the OS' is that is uses a single address space (SAS). Instead of running each process in a virtual memory space, all processes are running in the same memory space. This means that "context switches" do not invalidate memory caches. So processes run at the speed of lightweight threads. Security between processes is managed by both the compiler and the runtime. While SAS may seem less secure, NSA has certified several SAS operating systems for multi-level security, including the IBM System i5 (AS/400, S/38). Inter-process communications (IPCs) become trivial when two processes are allowed to address the same data spaces and call each other's methods (subject to the approval of the compiler and the runtime). All Oberon needs is Single Level Storage (SLS); another innovative feature o the System i5. There is a "Persistent Oberon" variant that offers an SLS-like framework for those people that want to explore that avenue.

Oberon the language allows direct manipulation of the hardware registers, so Oberon the OS is written entirely in a high-level language, without the need for assembly code.

Garbage collection in an object-oriented system is always interesting. We've seen how Java does it within the virtual machine, and Microsoft does it in .NET. Oberon uses a tree structure to reference all the objects, and does a periodic 'mark' sweep of the tree, looking for and marking reclaimable objects. It then does a 'sweep' pass, harvesting the marked objects. This mechanism is fast and reliable, but certainly subject to debate. And it's these types of debates that makes studying and learning OSs so much fun!

The newest version of Oberon, known as both Active Object System (AOS) or Bluebottle, combines processes with objects. Much like a Java object that extends "Runnable", every AOS object is capable of being a process by the declaration of the {active} attribute.

So, in review:
Simple High Level language
All source code available and reasonable well documented
Object-oriented
Late-binding and runtime reflection
Compiled
Trivial IPCs
Easy threading (any object can be a process and all processes are like threads)

Ported to several different processor families, minimal hardware requirements, live CD...

What more could you ask for from a learning/research OS?

- Brad

Ah, OK, I found what made me uneasy about it from the start:

"Oberon is completely object-oriented, much like Java..."

"Garbage collection..."

And I have this nagging suspicion that, on an Oberon OS, you have to use Oberon as a programming language...

Well, nice you got it to work, keep going at it, but I think I'll pass on this one.

DGDanforth wrote:One can choose to put (1) only the compiled code (2) code plus interface (3) source plus interface plus code.
The later (3) is the least secure. The first (1) is the most secure.

In essence, security through obscurity. Shame that it is considered a Bad Thing for quite a while now.

Rule #1 in cryptography: "The enemy knows the algorithm."

Applies to IT security as well.

Combuster wrote:

DGDanforth wrote:One can choose to put (1) only the compiled code (2) code plus interface (3) source plus interface plus code.
The later (3) is the least secure. The first (1) is the most secure.

In essence, security through obscurity. Shame that it is considered a Bad Thing for quite a while now.

That's got to be one of the stupidest remarks I've seen in a long while. If I can crack your code when I can see your code, it means you're stupid. If I can't crack your code when I can look at it, it means you're a very smart guy.

Try using logic. If you can't show me an error when I show you the code, you most certainly can't show me an error when I don't show you the code.

Candy, you might want to reconsider. The statement was that, in this Oberon OS, "OS modules and user modules are on the same footing and can easily be intermixed" - which Combuster and myself understood to mean "no memory protection".

And the answer to "how to you make the system secure, then?" was, essentially, "by not giving you the source". You will agree that this is not "security" by anyone's standards.

@ DGDanforth:

If Combuster's and my assumption was in error, please tell us.

Folks,
I think Bradw's response of Sept 17 is far better than the one I gave concerning security for Oberon.

Having said this I will stick my neck out and say "What's the difference between Oberon or Windows or Unix operating systems if you have the object files for the OS sitting on your disk?"

DGDanforth wrote:Folks,
I think Bradw's response of Sept 17 is far better than the one I gave concerning security for Oberon.

Well:

Bradw wrote:Security between processes is managed by both the compiler and the runtime.

That is what gave me the impression that the only valid programming language on an Oberon OS would be Oberon.

Nice for a research OS, but a complete show-stopper for me.

And it doesn't really mix with earlier claims, see below.

Having said this I will stick my neck out and say "What's the difference between Oberon or Windows or Unix operating systems if you have the object files for the OS sitting on your disk?"

*chop*



On Unix (and a well-configured Windows), a user cannot write into an OS object file on disk or an OS process in-memory, because of memory protection / disk access restriction. Actually, the whole partition on which my /usr directory resides is mounted read-only. There is a definite line between "OS code" and "user code". User code can be "promoted" to OS code by the root user (remount /usr read-write, copy object file, re-generate intrusion control checksum on my system), but the user cannot.

Either Oberon allows "free intermix" between user and OS code modules, or it protects itself against malicious users. I cannot see how it could do both.

And I would be interested in seeing how it were made possible, that's why I'm asking.

On Unix (and a well-configured Windows), a user cannot write into an OS object file on disk or an OS process in-memory, because of memory protection / disk access restriction. Actually, the whole partition on which my /usr directory resides is mounted read-only. There is a definite line between "OS code" and "user code". User code can be "promoted" to OS code by the root user (remount /usr read-write, copy object file, re-generate intrusion control checksum on my system), but the user cannot.

Either Oberon allows "free intermix" between user and OS code modules, or it protects itself against malicious users. I cannot see how it could do both.

And I would be interested in seeing how it were made possible, that's why I'm asking.

It's probably misleading to say that Oberon user code and OS code is not differentiated. OS code is still "privileged" and has the ability to set register status words (e.g. runs in Ring 0 in an x86 processor). User code does not. The real difference is that while UNIX/Linux/Windows et al use a monolithic kernel, Oberon has a "service module" for each protected resource. Very much like a microkernel. Or a set of microkernels, each responsible for controlling a single resource. The monolithic kernel versus microkernel debate is religious in nature (it was the original point over which Linus Torvalds and Andrew Tanebaum disagreed - http://www.oreilly.com/catalog/opensour ... /appa.html). Certainly early microkernels like Mach had dismal performance. With microkernel message passing, there are repeated calls from userspace into the kernel. Each call requires an expensive context switch. Context switches in a virtual memory system are so expensive because you have to re-load a new virtual memory map into the virtual memory manager, and flush all the caches. With a single address space (SAS) system like Oberon, all the processes share the same memory space, so there is no need to reload maps or flush caches when switching processes. Context switches are reduced to register stores and loads, usually implemented as a single processor instruction. There is no additional cost for my object/process to write into a buffer it owns and then call the disk control service module, passing it a pointer to the buffer. No context switching or memory mapping is required for the disk control service module to access the buffer, since they occupy the same memory space. Sort of like DMA between processes. So think of Oberon as a microkernel without the performance drawbacks. If you don’t like microkernels, you won’t like Oberon

Oberon is a research operating system and lacks a number of features that are mandatory for a commercial operating system. While Oberon does not currently seem to offer protection of processes from other malicious processes, the protection of processes in a single address space is well known. “Capability-basedâ€

I see I have been recognized. Well, Java is an improvement over Oberon in my book, at least as far as "mainstream compatibility" is considered.

But this talk about Oberon microkernel vs. Linux monolithic kernel bothers me. Do I understand correctly that your "OS service modules" all run in ring 0, and the same address space? If so, could you put your finger on how this is different from Linux kernel modules?

It seems to me to be equivalent to kernel modules, each with their own dedicated thread..

But this talk about Oberon microkernel vs. Linux monolithic kernel bothers me. Do I understand correctly that your "OS service modules" all run in ring 0, and the same address space? If so, could you put your finger on how this is different from Linux kernel modules?

It's not different at all. Ring 0 code can access hardware and other protected resources. Userspace code can't. Works the same whether its Linux or Oberon. The key difference is the cost of crossing the "barrier" between processes and consequently Rings. In a virtual memory operating system, each process is running in its own memory space, e.g. each process begins at its own virtual location zero. To switch from one process to another, the virtual memory map must be reset and all the cached memory locations must be flushed. This context switch takes a long time. Consequently, you try to avoid crossing back and forth across processes as much as possible. This is the reason for moving as much code into the kernel as possible. Once you cross into the kernel and are running kernel threads, you want to keep going and avoid having to stop and do a context switch back into another process. This is why things like the khttp web server have been moved into the kernel. You can access all the kernel data structures, serve web pages and access the disk, all without having to switch context.

Oberon is a single address space operating system. All the processes are in the same memory space. Process 1 may be at location zero, Process 2 may be at location 1000, etc. When you switch between processes, you still have to save the processor hardware registers, but you don't have to reset a virtual memory map and all the processor caches remain loaded. After all, you didn't change the memory space just because you changed processes. So, a single address space configuration avoids the high cost of a context switch. I can hop in and out of privledged (Ring 0) processes as often as I want (yes, there's still overhead but a much smaller one). Additionally, I don't have to execute lengthy IPC code to move data from one process to another. If a process has the right permissions, controlled through resolved pointers, it can directly access the data in the buffer of another process.

Nothing comes for free. I can see people saying "directly access another process's data? - what a hacker's paradise!" The "protection" of virtual memory isolation must be replaced with another type of protection mechanism in a single address operating system. Protection mechanisms like runtime access proxies have a processing overhead. Single address space operating systems have achieved the same levels of security ratings (and here I'm refering to the US Department of Defenses's Orange Book) as UNIX and Trusted Linux systems. So, inter-process protection can still be achieved. We all know that the security of an operating system has more to do with its configuration than its design (Solar refers to the excellent practices of making the entire disk containing executable code read-only and of comparing MD5 signatures).

So, there are trade-offs in all solutions. The fun is in exploring the differences and their costs.

I'm certainly not going to try to make the case that Oberon and SAS are better than any other operating system and memory model. Just different. I think Bernhard's purpose in starting this thread was to bring this different to light and to facilitate a dialog from which better ideas can flow. And we seem to be off to a good start.

Google(define: microkernel) wrote:A system kernel that runs itself in protected memory space, and all drivers and processes in a seperate memory space allowing for (theoretically) better stability.

There seem to be different definitions of a "microkernel" out there, some of which refer to servers being in a seperate address space (like the one above). So, is it actually possibly for a SAS system to be classified as a microkernel? Especially when all memory protection is implemented via proxy?

Singularity is a single-address-space system (at least it is by default -- it is configurable), and it is generally regarded as a microkernel.

Being a microkernel architecture has more to do with how the OS is structured than in how its processes and IPC are implemented. If most of the OS is composed of processes that communicate via message-passing, I would argue it's a microkernel, even if the processes are software-isolated and the message passing is zero-copy within the same address space.