BRiX - Operating System

How can a single address OS be secure and have multiuser support ? Won't a user be able to write over someone else's code/data ?

BRiX uses a safe-language that compiles in runtime checks to prevent all code, including user code, from writing outside of its boundaries. After the core system code and libraries has proven to be stable these checks will be removed and the code will outperform the code in multiple address space OSes.

I'm not sure if your confusing single address space with something else but it has nothing to do with multiuser. Try to be more specific if this doesn't answer your question.

The security in comes from the fact that there is no way to overflow buffers because of the safe-language. BRiX will not execute code unless it was compiled by the safe-language on the curent machine.

Another security features is the lack of a file system. All objects are referenced by the central database system and its query function are restricted to code approved by the admin. This prevents malicious code from gaining references to objects it shouldn't be accessing. Objects can't be accessed without a reference and the safe-language does not allow code to generate random references.

This means an intruder can only access the exploited object and any objects referenced by the object.

Hey Brand,

Do you have any documentation on all the ideas you have for this project all consolidated at one place so that a newbie like me could read and jump into the development if interested.

Also, is there any documentation on the code written so far so that for the one who is entering the development, understanding becomes easy.

Harshal.

The only documentation is at http://brix-os.sourceforge.net/?p0=info. You can learn to write programs with Crush at http://brix-os.sourceforge.net/?p0=info&p1=crush. The macro-* files in the Crush source contain macro usage at the top of each function. The call.c file lists all the aliases for each macro. Some of these macros are documented on the Crush webpage but I haven't got around to documenting the math, boolean and bitwise macros.

To write Crush code just create or edit a *.cr file in the brix/core/ directory and run `make` from the brix/ directory.

Let me know if you can't find documentation on something you're interested in.

"BRiX uses a safe-language that compiles in runtime checks to prevent all code, including user code, from writing outside of its boundaries. After the core system code and libraries has proven to be stable these checks will be removed and the code will outperform the code in multiple address space OSes."

While I applaud the concept, it won't work in reality. Correct me if I'm wrong, but a program that seems to behave properly (not writing outside of its "boundaries") cannot be known to always behave properly. There could be unforeseen issues which would cause some pointer to be writing to memory outside of its allowed data spaces.

Are you using isolated processes? Such as assigning them their own GDT or LDT entries with a base and limit of whatever is required? If so, why even bother with checks? The OS will trap any write-fault errors.

- Rick

"There could be unforeseen issues which would cause some pointer to be writing to memory outside of its allowed data spaces."

Such as hardware failure or radiation flipping bits? How does hardware protection help if the data or code inside kernel space is affected?

"Are you using isolated processes?"

No. Hardware protection only tells us the program wrote outside of its boundaries while software protection can throw a specific exception for the out of bounds array index and the code may even be able to recover.

"Such as hardware failure or radiation flipping bits? How does hardware protection help if the data or code inside kernel space is affected?"

FWIW, most hardware failures are corrected by ECC, both in cache and in logic units, on most modern processors. Aside from that, the hardware protection mechanisms are designed to prohibit errant code from destroying anything other than that which the operating system has allowed that task to have access to. The hardware will trap the error before it happens, such as write on NULL pointer, or write into a memory region the app is not supposed to write to.

"No. Hardware protection only tells us the program wrote outside of its boundaries while software protection can throw a specific exception for the out of bounds array index and the code may even be able to recover."

Hardware tells you that an errant assembly instruction tried to write out of its boundaries. It does not commit the write, otherwise it would be useless. It throws an exception (of whatever kind) to the OS, which can examine the code, the assembly instruction, data about the process, and then determine what to do.

For properly debugged code, errors should only come up when there is a previously unknown error in the program, or if there is some other form of error causing the code to act in an unexpected manner.

Hardware protection mechanisms are completely free and, to my knowledge and understanding of your runtime checks, allow for faster code, the same debugging and trapping abilities as well as much greater protection.

- Rick

"The hardware will trap the error before it happens, such as write on NULL pointer, or write into a memory region the app is not supposed to write to."

Most references in Tetra can not be NULL and those that can are *ALWAYS* checked at runtime. Good C programmers check for NULL pointers before they are used so these automatic runtime checks don't slow down the program.

Tetra uses bounds checked arrays so it is not possible to access elements not inside the array (buffer overflows). Using the abstractions Tetra has to offer eliminates the runtime checks while maintaining the safety.

And Tetra has no pointers or pointer arithmetic so there is no way to write code that can unexpectedly write to random memory.


"Hardware tells you that an errant assembly instruction tried to write out of its boundaries. It does not commit the write, otherwise it would be useless. It throws an exception (of whatever kind) to the OS, which can examine the code, the assembly instruction, data about the process, and then determine what to do."

It kills the program and presents the user with an ugly error message. Software protection gives the program a chance to recover and when the code can't recover it can usually terminate properly with an informative error message.


"Hardware protection mechanisms are completely free and, to my knowledge and understanding of your runtime checks, allow for faster code, the same debugging and trapping abilities as well as much greater protection."

So loading a new page descriptor on a context switch is free? If transitioning from user space to kernel space is free then why do most operating systems move graphics, networking and other speed critical drivers into kernel space? If passing data between processes is free then why do they use copy-on-write and other hacks when passing data?

Hardware protection creates barriers that make it more difficult to write modular systems. Moving code into the kernel to make it faster also adds security and instability problems because the hardware protection does not work when kernel code crashes.

"It kills the program and presents the user with an ugly error message. Software protection gives the program a chance to recover and when the code can't recover it can usually terminate properly with an informative error message."

The error in the program does not have to present the user with an ugly error message. Well formed applications, especially at the operating system level, could incorporate higher level concepts, such as exception throwing. As your code is executing you could call an OS API which would indicate where the exception handler is (as is inserted automatically--to handle scoping--by the compiler). When anything errant happens, the appropriate exception is thrown and handled politely.

The advantage of using this model is that the code and data is assumed to be correct, thereby not having to double-check everything. The only time when the application handles an error is when an error occurs at a given point and time, and only then does it process extra steps to handle the error.

"So loading a new page descriptor on a context switch is free?"

When an error occurs, it is not slow relatively speaking, as the entire context switch is handled in 100s of clock cycles. When a CPU is operating at 3.0 GHz, for example, that equates to a miniscule amount of time.

"If transitioning from user space to kernel space is free then why do most operating systems move graphics, networking and other speed critical drivers into kernel space?"

Because they have freer reign of the system at PL0. Plus, that code is core, trusted code and should be executed at PL0 in a well-designed system.

"If passing data between processes is free then why do they use copy-on-write and other hacks when passing data?"

Because most OSes cannot know in advance the type(s) of software that will be executing on it. As such, they code for the worst. The copying idea is designed to leave the errant code in pristine state, thereby having no chance of corruption.

However, since you are the author of your OS, you could include code which would not require a duplication of the data space, but rather a separate LDT or GDT selector which gets mapped into that space for the duration of the debuggin session.

"Hardware protection creates barriers that make it more difficult to write modular systems."

I disagree with that statement because hardware protection mechanisms can be created which do not create barriers. However, their use in that regard is not found widely in bulk OSes for whatever reason(s) (to which I do not understand because the core architecture itself--x86--can handle it).

"Moving code into the kernel to make it faster also adds security and instability problems because the hardware protection does not work when kernel code crashes."

Hardware protection still works when kernel code crashes. You can have multiple PL0 apps which are stalled in debugging. It all depends on how you setup your task management and how you isolate critical code. I have actually used my own debugger to debug problems with my debugger code. :) I had to setup some special traps and features to enable/disable blocks of code where I knew there was a problem, but it works. The hardware provides everything you need, and does so without the obsfucation layer imposed by most mainstream OSes.

If you're interested in learning how it can be done I would be happy to show you. Note also that I'm not debating you here, I just have some expertise in this area having spent so many years working on developing my OS, and learning that the methodologies in place by other mainstream OSes are inconsistent with the fundamental principles and philosophies inherent in the raw x86 architecture. The extent to which their software-enforced protection mechanisms operate obsfucate the underlying hardware mechanisms, those which actually make it very easy to deal with all sorts of traps and everything else.

I'll await your reply (in email, hopefully).

- Rick