Slashdot Mirror
Crush/BRiX: An Experimental Language/OS Pair
An anonymous reader writes: "Brand Huntsman (the creator of the Bochs Front-End, among other obscure things) has been developing an integrated language/operating system for the past few years now. The Operating System is called BRiX, and it uses a language called Crush, which is woven tightly into the core of the OS. On his project web page he has posted the source code to his preliminary compiler, which runs in Linux and outputs optimized assembly from Crush source code. The Crush language itself is heavily influenced by Forth, LISP, and Ada, and provides strong typing and extensive namespace security." Update: 08/19 00:03 GMT by T : Note, the project page URL has been updated, hope it now works for everyone :)
I didn't read the article, but I definitely am setting a few kilobucks aside of Crush/BRiX goes public. It appears that BRiX's namespaces delve deeper than traditionally as in C++ or Java, where a malicious programmer can get around the namespace compartmentation via direct addressing. A particular nasty example of this was recently reported on BugTraq, where filesystem access logs could be circumvented by creating a hard link to an arbitrary file, accessing the file through the hard link, and deleting the hard link. File access would not be logged, and past logs would be compromised. Although this is only tangential to namespace security in programming, I find it quite reassuring Mr. Huntsman is taking the initiative to push forward computer science and information technology security. Hopefully, the ideas presented by Crush will be widely adopted by commonplace languages such as Perl and Logo in years to come.
I'm probably going to get moderated down for this, but I couldn't help but notice the similarities between Crush/BRiX and Microsoft's .NET framework.
Crush doesn't use protected memory to protect applications from each other, but instead relies on the language, Crush, to ensure programmatically that it is impossible for programs to interfere with each other. This is almost exactly the same as a .NET application domain (ASPX or IE would be a single application domain); there isn't any enforced seperation of processes or security features running in an application domain - the CLR instead formally proves that the applications running don't violate the security boundaries it's supposed to conform to.
I'm wondering if this is an idea whose time has come, particularly in the field of low-cost embedded development. Instead of including costly hardware and OS support to provide these features, you use software development tools to create software which renders them unnecessary. Or am I just smoking crack?
I don't understand why that posting got rated Troll, except from the slightly offensive language it is a very insightful comment.
By placing the security model in the language rather than the OS design you will get some disadvantages. You will either have to limit yourself to applications written in this single language or loose the security. Of course some kinds of frontends can get other languages compiled into something running on the system. But this is likely to give you some penalty in performance and perhaps other areas as well.
The language is probably usable on other OSes as well, if anybody care to write the necessary compiler and libraries. But you might not get the full benefits from the language.
However the main idea isn't new. Some people seriously believe JavaOS has a future. Generally you get a uniform security model all the way from OS core through library layers all the way up to the applications. You get runtime typechecking, boundary checking, and garbage collection. You prevent half of the possible security problems. And people believe that good JIT compilers can be faster than compiled C code in some areas where runtime code analysis can be used to do optimizations not possible at compile time.
Do you care about the security of your wireless mouse?
May I ask you how FORTRAN is a) integrated with it's OS (whatever that really means in the case of FORTRAN), or b) integrating the development environment with the software under development?
This approach has numerous predecessors,
not the least of which is Oberon, Lillith, Mesa, the Perq, and on back to the Burroughs B5500. Admittedly
the Burroughs machine had hardware segmentation support, but it had no notion of "privileged state" - the Algol compiler wouldn't produce code that could do "bad things". about a decade ago the hot topic in OS Research papers was all about how to use huge address spaces and the one-address-space model was resurrected again, with and without various hardware support for compartmentalization.
If you believe a compiler will never generate erroneous code, you'll sleep just fine with this model. On the other hand, if you've debugged a system compromise caused by a compiler bug, you might feel otherwise.
pleasant dreams
I hate to break this to you, but C is just as tightly woven into Unix, as anyone who has tried to implement a compiler for a higher-level language will tell you.
For example: Suppose your language wants to manage a stack differently than C does. Suppose, for example, you want to perform some optimisation where the stack pointer does not point to the true end of the stack (say, in a leaf call). Under Unix, too bad. You need to maintain a true C stack pointer otherwise signals won't be delivered properly.
Unix is just as much a C virtual machine as the Symbolics devices were Lisp virtual machines.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});