BRiX - Operating System

So what's to stop someone with a binary editor from taking a safe-compiled program and altering memory addresses in the binary? Checksummed files or something? Seems easily hackable...

All code MUST be compiled on the user's machine, no binary distribution. If the user wants to hack herself then so be it.

So any local user can write a program, compile it, and hack it to stomp all over the kernel? How can you have a secure, multi-user environment? Or is BRiX not meant to be multi-user?

Crush is a safe language which means you can't write code that does bad things. However, the admin, or any user with the proper settings, can access the low-level features of the language.

With these features it is possible to do anything and if the admin wants to mess up the system then so be it.

I thought the idea is that users don't have permission to directly modify the bytes of their own compiled programs since they aren't really files..

They are merely objects.

The user does not have any direct way to access the internal representation of that object (ie the compiled binary).

Or do I have the wrong idea?

Ah, I see. That makes sense. Hmm... maybe I've spent too much time with UNIX.

Paul Richards is correct. Not even the admin has that ability. The admin, however, can add assembler code to any component and then recompile.

How can you say that any language is a safe language? You talk about having checks, which makes sense to deter any errant code from affecting anything (especially on a flat model with no hardware security)... but no code is perfect. Once those checks are removed then the possibility exists to have errant code take down the entire system.

That was the whole point behind the 32-bit hardware protection mechanisms added to the x86 line. The hardware would signal before something bad happened, and then you could politely shut down the app.

To have everything run in the same PL is inviting disaster on a scale heretofore unseen in operating systems because no other OS writer has looked at that potential problem and said "Ah, heck... let's go for it". They step back and say: "Oh, I've got these hardware mechanisms in place, let's go for it."

I would suggest removing paging from your vocabularly, but making sure you have the basic descriptors setup properly to allow the OS to trap any errant code writing outside of its space. You can always setup OS API calls which would allow inter-process shared writing via a new descriptor pointing to a shared area, etc.

There are ways to utilize hardware in an intelligent manner. It doesn't have to be (and cannot be truly) done through any compiler or "safe language" extension. That is unless you know something I do not.

I'm anxious to hear your replies to my posts.

- Rick

"Once those checks are removed then the possibility exists to have errant code take down the entire system."

But the checks are not removed. There are only a few rare cases deep within the system where specific checks may be removed for code that can be proven correct. Keep in mind this is for system level code which would be completely unprotected even if the OS used hardware protection. Code containing these overrides is not user installable.

"I would suggest removing paging from your vocabularly, but making sure you have the basic descriptors setup properly to allow the OS to trap any errant code writing outside of its space."

"There are ways to utilize hardware in an intelligent manner. It doesn't have to be (and cannot be truly) done through any compiler or "safe language" extension."

A safe language provides fine-grained protection, something hardware can not do.

With hardware mechanisms you provide protection in logical block sizes, such as 4K segments. Additionally, the protection mechanisms present on hardware will point to the exact assembly instruction which caused the errant code, thereby pointing to the exact location where the problem exists.

- Rick

Did you know that most data is smaller than 4k? Software protection can scale down to one bit!

https://sourceforge.net/forum/message.php?msg_id=4061100

"Did you know that most data is smaller than 4k? Software protection can scale down to one bit!"

It is desirable to have data blocks in manageable units, those which can be swapped out to disk when needed (and without paging).

I have never seen a need for paging. Paging is what slows down most systems notably. If you stick with raw GDT/LDT base+limit and then handle the physical memory locations on your own you will gain speed. For most applications with modern day system amounts of memory, such as a PC with 1 GB of RAM, it will never be an issue.

I welcome the opportunity to discuss this with your further.

- Rick