Slashdot Mirror

EROS is hard to describe. It's capability-based and has orthogonal persistence -- and if that doesn't mean anything to you, I'm not going to be able to explain it much better. Check out the EROS project site and read the documentation. One thing this means that I can explain, though, is this: "snapshots" are taken of the current state of the system every five minutes. If the power goes out, the system is later restored to the last good snapshot. So you could have a text editor window open, never save your file, PULL THE PLUG on your computer and then plug it back it. Within 30 seconds (or however long your BIOS POST takes to complete), your text editor window is back on the screen, and you've lost no more than five minutes of work.

EROS is cool. I think it has potential to be the Next Big Thing. Check it out, download it (it's GPL'ed), play with it. Have fun.
-----
The real meaning of the GNU GPL:

EROS is hard to describe. It's capability-based and has orthogonal persistence -- and if that doesn't mean anything to you, I'm not going to be able to explain it much better. Check out the EROS project site and read the documentation. One thing this means that I can explain, though, is this: "snapshots" are taken of the current state of the system every five minutes. If the power goes out, the system is later restored to the last good snapshot. So you could have a text editor window open, never save your file, PULL THE PLUG on your computer and then plug it back it. Within 30 seconds (or however long your BIOS POST takes to complete), your text editor window is back on the screen, and you've lost no more than five minutes of work.

EROS is cool. I think it has potential to be the Next Big Thing. Check it out, download it (it's GPL'ed), play with it. Have fun.
-----
The real meaning of the GNU GPL:

That's funny, I thought that Unix was based on a monolithic kernel... silly semantics

I see Unix being more able to adapt in todays fast changing Information Technology world than other operating systems based on monolithic kernels.

But that's not what I really wanted to comment on.

I would love to see some of the best coders and operating systems people put together a new OS from scratch using the latest techniques.

Ideally this would create an ultra stable

working with Photoshop (etc).

Alternatives are out there. You just haven't found them.

-rt
======
Now, I think it would be GOOD to buy FIVE or SIX STUDEBAKERS
and CRUISE for ARTIFICIAL FLAVORING!!

To me, it seems the only right way to go from Unix. Because Unix won't be the ideal system forever. What do you think, is EROS too complex to survive?

This is SO cool! With this stuff you can turn your computer off, turn it back on and be right where you left off!

EROS does this. It looks very, VERY cool. Its GPL'd so I don't think anyone here will mind. Has anyone here tried it?

Yeah, the page is down, like I said. It crashed a few weeks ago and hasn't come back up. There's a link at the bottom...

Anyway that's kind of the point. It went down and the people running it haven't brought it back up (but surely next time it will come back bigger and better! - so they dream). Giving the developers more freedom killed it because, no longer limited by the engine, they all had these grandiose visions of incredible games which they really couldn't finish.

Anyway, back on topic, I mentioned EROS(seemingly also down...), because one of its big things is persistent store. Instead of having a filesystem, it just has the most incredible virtual memory system you've ever seen. Efficient multithreading is also really the OS's concern; it can do it so much more efficiently with special code.

As for QuakeC, a massive multiplayer RPG is much more complex than Quake. Imagine trying to track everything you do in a MUD while running a Quake match between 400 people.

Also, for your primitives to do most of the work, you need to have a very close idea about what your going to be doing with those primitives, meaning a very specialized and limited engine. I don't dispute that scripting languages in games can be valuable tools, but there's a big difference between a specialized scripting language you use to define the top level interactions and a "sky is the limit" wide open general purpose interpreted language that you use to place the scales on a dragon's back.

You've gotta wonder, is it worth all that effort to put another layer between the implementor and the hardware?

Since a few people seem to be interested, I will recapitulate the overall HURD status, from my personal experience and my reading of the debian-hurd and bug-hurd mailing lists.

First, is it usable? Well, it depends for what. It is still quite unstable. Filesystems are under active development, but there are still some problems with them (the ``native'' Hurd filesystem, if that means anything, is ext2 just like Linux, but the ext2 demon still has problems, one of them being that sometimes entire file blocks are replaced by zeroes — this will be fixed soon). The TCP/IP stack is a copy of that of Linux (but the Hurd maintainers are having trouble keeping up with the changes made to the Linux networking code). The security mechanisms are extremely flexible but that sometimes causes problems (for example, the Hurd has one more set of file permissions besides user, group and other permissions, the ``not-logged-in'' permissions, and no tools yet exist that will allow to manipulate these permissions). There are also some strange limitations: for example, Hurd will not work on a partition of more than 1Gb, and it crashes rapidly if not given a swap partition.

X Windows will work with a set of patches. Some other programs cause problems, and sometimes it's the program's fault (because it makes assumptions about the Unix-like nature of the system which are not verified under the Hurd).

On the other hand, the Hurd is stable enough to bootstrap itself (compiler, microkernel, libraries, demons) and perform tasks that do not have stringent hardware requirements.

The Hurd shares the same libc as Linux (the GNU libc, currently version 2.1.2). So eventually it should be binary compatible with Linux (right now it is not, but there is no severe problem with that, it is only a matter of time). This is one of the great hopes of Hurd, the possibility of making the transition completely smooth.

The slowness of the progress on the Hurd is due to nobody working on it full time. Some very competent programmers are devoting a lot of time to it (Thomas Bushnell, Brent Fulgham, Roland McGrath, Marcus Brinkmann and certainly a few I'm forgetting), but they are overwhelmed by the immensity of the task.

In theory, though, the Hurd should be easier to develop than Linux, because it is more inherently modular, and because of the fantastic possibilities of gdb under the Hurd. Also, you do not need to reboot to test changes to the ``kernel'', and you can debug a live kernel without problem; plus, you can test some experimental features without endangering the base system. So, there is no reason that Hurd can't become very solid and stable — quite the contrary in fact. But they just need more volunteers. And the FSF unfortunately cannot affort to hire someone on it full time (say, why not write a check to the FSF specifying that you would like to see it employed for Hurd development?).

On the other hand, in the domain of performance, it is probable that a microkernel architecture can never be at par with a monolithic kernel, at least on single-processor machines. For the moment, the Hurd is horribly slow with filesystems (rm -rf is just a nightmare), but this is mostly because it is completely unoptimized. Still, even when it is, it will probably remain noticeably slower than Linux. It has been claimed, however, that the difference may be significantly less than expected; but it is yet too early to see.

The main advantage of the Hurd is its flexibility. User-land filesystems are part of that. In fact, you do not even need to be root to write a filesystem. (That is one of the things which angers me the most about Linux, the need to be root to mount a simple loopback file.) The Hurd is completely virtualizable, whereas Unix hardly is (well, there is a ``user-mode Linux'', but it is even more experimental than the Hurd), so any user can set up her own virtual sub-hurd with its own set of users, permissions and so on. The security system is soooo flexible: much better than access control lists, it uses capabilities (àla Eros) in the form of Mach ports. If this were made practical, this would be a huge gain on the security side, because you would practically never need to be root for anything, just introduce the ad hoc capabilities and permissions. And the virtualization possibilities let you surround dangerous demons by ``sanitary cords'', making the system much harder to break into. So, theoretically, the Hurd can be a very secure system. Finally, the whole translator system can be used in yet unthought-of ways to provide wondrous communication mechanisms between programs.

However, the real question now is whether binary compatibility with Linux plus the great extra features and flexibility can be sufficient motivation for people to move to the Hurd when it is more stable, and, in the mean time, for more developpers to draw their attention to it. The lack of hardware support, on the other hand, is not a big problem: Roland McGrath has an experimental project for making the Mach microkernel run with the Flux OSKit, so that all the Linux hardware support would immediately benefit the Hurd.

Capability-based security is what you need.

See Eros. It's GPL'd.

Is Linux's popularity a threat to other open OS projects? Even now, it seems all other free (and even non-free, I guess) unices will want to have binary compatibility with Linux. And as more and more users just use binary software distributions, there will probably soon be no reason for anybody to actually create BSD, Hurd or whatnot binaries. Except that Hurd doesn't run Linux binaries at the moment... right :)

Linux has been made to run on top of a microkernel and one of Hurd's frequently asked questions seems to be if Hurd could be run using Linux as microkernel. The answer doesn't actually say it couldn't.

What about the EROS operating system? I read once about it in Slashdot and on holidays I've spent some time reading its documentation. Seems very interesting, the whole capability system concept, no traditional filesystems, persistence and all. Yeah, they seem to be designing a Linux environment hosted under Eros or something like that.

But what if Linux people just somehow weave the capability model and persistence into the Linux kernel? What will that do to EROS? Is Linux so popular, that people would blindly use it also for tasks for which it doesn't suite at all?

As a GPL-protected project, Linux can never become a new Windows, but could it become a threat to natural diversity in the open source world?

What do you think of capability-based systems, such as EROS? The folks who are working on these systems say they are fundamentally more secure (against both malicious code and heisenbugs) than Unix derivatives, Windows NT, and other ACL-based operating systems. Do you agree with this assessment? Do these systems have security weaknesses that Unix-like systems don't have?
--
"But, Mulder, the new millennium doesn't begin until January 2001."

There is no reason for them to run Windows either. Windows in itself is too big and scary for many users, and Word and Excel are just plain awful. A really easy to use OS would, I guess, be persistent (system state stored on the disk, as in EROS, all programs being always up and running. Then there would be a menu with big icons for word processor, spreadsheet, www client etc, and always a way to pop that menu back up. All the standard programs would be "running" all the time, all of them would take up all the display while being used. As easy as a PDA or cell phone (at least older Nokias are pretty simple to use, surprisingly the new ones seem more irrational to me).

No use to tell people that command line is fine, when even the freedom given by Windows is too much for many of them.

1. IMO, The Star Wars Crap Made Out of Legos is clearly some of the most interesting and best made of the new generation of Star Wars Crap.
   
2. The mark of a good operating system is not "tight code" but "tight design." What follows is a list of design points, with OSes having interesting solutions in parentheses where relevant.
   
   • Does the kernel manage system resources properly? [Win9x and MacOS What security model does the kernel present? [EROS]
     
   • Does the kernel manage time well? N.B. "Time" means both "latencies" as well as "handing events and doing work over time." [BeOS]
     
   • What namespace abstraction is presented to software in a system and/or to a user of a system? [Plan 9, Lifestreams]
     
   
   And the list goes on... but this should get the idea across. While this system may be free, what does it offer that the community needs?
   

You will note that EROS takes the idea of reducing the number of nodes closer to the root of the tree as far as possible. (The introductory essays are particularly valuable to read.) Every program is passed exactly the access it needs to have which means that there are far fewer programs which run as root or something close to root (the pun with the root of the attack tree is unintended) and therefore there are a lot fewer potential ways to try to break the security.

For those who do not want to read the essays in detail, here is an explanation "from 20,000 feet" to give you a sense. Unix is based on the idea of an access control list. You have permissions based on who you are, and every process you run will (by default) have permissions to do on your behalf anything that you can do. EROS is based on the idea of a capability. Capabilities can be thought of as handles through which you can request some action and you can do nothing without explicitly being handed the appropriate capability.

The difference is obvious when you consider trying to cat a file. In Unix you hand a program like cat the names of the files you want it to open and trust it to do nothing other than what you asked. In EROS you have the capability to produce capabilities which we will call file-handles would hand cat the open file-handles from which it could read those files and be guaranteed that it is unable to talk to anything other than you, or read anything other than those files, since it has no other capabilities (not even the ability to produce another file-handle). Note that in Unix you explicitly have to trust that cat won't do anything else while in EROS there is no way that it could.

This ensuring that processes never have any ability that they do not need to have results in far fewer processes with sufficient permission to cause damage, and therefore results in the attack tree by default being substantially pared down from what is possible even in a heavily locked down Unix system. As a result verifying the security of the operating system becomes a far simpler task. While attempting to verify the security of a Unix system is possible, the OpenBSD folks have done an extremely good job of it, the equivalent task for a capability system is far simpler.

Food for thought. :-)

Cheers,
Ben

You will note that EROS takes the idea of reducing the number of nodes closer to the root of the tree as far as possible. (The introductory essays are particularly valuable to read.) Every program is passed exactly the access it needs to have which means that there are far fewer programs which run as root or something close to root (the pun with the root of the attack tree is unintended) and therefore there are a lot fewer potential ways to try to break the security.

For those who do not want to read the essays in detail, here is an explanation "from 20,000 feet" to give you a sense. Unix is based on the idea of an access control list. You have permissions based on who you are, and every process you run will (by default) have permissions to do on your behalf anything that you can do. EROS is based on the idea of a capability. Capabilities can be thought of as handles through which you can request some action and you can do nothing without explicitly being handed the appropriate capability.

The difference is obvious when you consider trying to cat a file. In Unix you hand a program like cat the names of the files you want it to open and trust it to do nothing other than what you asked. In EROS you have the capability to produce capabilities which we will call file-handles would hand cat the open file-handles from which it could read those files and be guaranteed that it is unable to talk to anything other than you, or read anything other than those files, since it has no other capabilities (not even the ability to produce another file-handle). Note that in Unix you explicitly have to trust that cat won't do anything else while in EROS there is no way that it could.

This ensuring that processes never have any ability that they do not need to have results in far fewer processes with sufficient permission to cause damage, and therefore results in the attack tree by default being substantially pared down from what is possible even in a heavily locked down Unix system. As a result verifying the security of the operating system becomes a far simpler task. While attempting to verify the security of a Unix system is possible, the OpenBSD folks have done an extremely good job of it, the equivalent task for a capability system is far simpler.

Food for thought. :-)

Cheers,
Ben

Check out these two points in the availability section of the FAQ :


- Is EROS Free Software? What are the terms of use?
EROS is not free software. EROS is being made widely available for personal, research, and certain non-profit use. All such use must be non-commercial. It will also be made available under reasonable licensing terms for commercial use.
Draft versions of the license agreements can be found here. The draft licenses are an attempt to compromise between making the system widely available and not losing my shirt. These drafts can be taken as a reasonable indication of intent, but please note that they are not yet final.
Many people seem to have the idea that EROS should be given away in the style of Linux or the various BSD-like systems. These people are entitled to their opinions. I do not share them.
I have put a large amount of effort and my own money into this project -- teetering on seven figures, when last I sat down to calculate it. I have absolutely no sympathy for the idea that writing a few hundred lines of driver code should give you the right to free use of this work, so please don't delay the release by trying
to convince me with an argument of this form.
If you build a good driver, I'll gladly incorporate it into the system and redistribute it for you. If you want that driver to have the BSD copyright so that others can derive from it, that is fine. For the present, I am not incorporating GNU-copyrighted materials into the core system.


- How about Open Source?
It may prove, in the end, that the Open Source model is the best way to advance a commercial EROS effort. We are tentatively leaning that way. If so, that decision will be taken as a strategic marketing choice. When the time comes to make that decision, we'll solicit input from the community. Please don't distract us from getting the release out by pressing the matter now.
If we do go the Open Source route, we will do so with at least one modification:
Because EROS is a secure system, there needs to be a central source that ``vets'' and ``brands'' the distribution. When somebody asks ``secure according to whom?'' There needs to be an answer. Also, people need to know if they are running the vetted version or some modification of that.
This means that we will be fairly strict about the use of the name ``EROS.'' If you distribute a modified system, you will be able to call it ``EROS derived,'' but you will not be able to call it ``EROS.'' The official release will also be digitally signed or one-way hashed so that users can verify its authenticity.
The implications of this issue have not yet been thought out. As I said before, we will solicit input at the appropriate time.


Obviously the FAQ hasn't been updated, but I still think it gives us insight on their attitude. Considering how the author felt like a the time, I don't quite understand how he finally went to release EROS under the GPL. It seems like a big turn around...

According to the Programmer's Intro, you can get direct access to the hardware via keys. Very direct in fact; the kernel just confirms that it won't get toasted, then lets you loose. I'm not sure how close to real-time it gets--the key itself is still in the way--but it's better than nothing.

Where exactly does it say it is realtime?

From the FAQ:

The result is a small, secure, real-time operating system that provides orthogonal persistence.

Admittedly this point is not stressed on the EROS web site nearly as much as the capability system is.

The weak security of most operating systems permits the proliferation of viruses. The weakness is not in external security, but in the blanket access control given to users and the applications they invoke. An application generally has permission to do anything which the user who invoked it could do. Instead, some operating systems such as EROS and KeyKOS implement the capability security model. This allows users to specify which capabilities they will pass along to objects they invoke. Thus, a user does not grant blanket permission to a program to modify other programs, as is required for virus propagation, or to format the hard disk, as some viruses may do. The user simply grants it permission to create a few objects (files) of a particular type in a particular location (directory).

On the other hand, if I want to sit down and write an open-source application in my spare time, using C or C++, why should I do it for Windows rather than Linux/*BSD? I'd have to invest a lot of time and effort into learning the Win32 API, and that knowledge will become obsolete in three months. The time that I spend fixing Windows-specific bugs will cut into the time I have available for fixing Linux/*BSD-specific bugs. I don't see how experience with Win32 (as opposed to, say, EROS or PalmOS) would help me learn things about the general craft of programming that I couldn't learn from experience with Linux/*BSD alone.

In case you did not notice, RedHat is funding a security audit of their distribution. As a result there are many announcements of security holes - but this is a side-effect of improving security.

OpenBSD did this a while ago you say? Sure. But read those announcements because if you are using the same applications that the Linux folks are, then you are vulnerable. Security holes are things that tend to build up over time.

In fact security is a constant problem with the *nix organization. If you want to see a fundamental design which can lead to far more security than either OpenBSD or Linux, take a look at EROS.

(Solution to root-exploits, get rid of the possibility!)

Cheers,
Ben

I've been thinking about something similar - have a look at EROS and Mungi. I think a complete break with Unix will be necessary sooner or later - a security model which allows any program to delete all its owner's files is not strong enough for modern software distribution channels - with a system based on beta code from the internet you are running a lot of untrusted code, and (unfortunately) Open Source development/distribution will start to attract malicious hackers sooner or later. We are wide open.

If we break with Unix we can dump the command line - if you have a scripting language which can manipulate and communicate with objects, you don't need a shell. This would improve usability a lot - whatever people say about Gnome/KDE, Unix is still hard to learn, because to do anything advanced you have to use obscure shell commands.

So, what language are we going to write this wonderful, capability-based, object-oriented, network-transparent OS in? Java? Too slow - the insistence of the designers on creating a portable binary format means it will never be as fast as native code. For Open Source development we don't need a portable binary format - we can distribute the source code and compile it into native object code on the target machine (transparently to the user if necessary). Java also contains various security hacks which would be unnecessary under a secure (capability-based) OS. So we want something similar to Java, but simpler. An object-oriented language designed for efficiency rather than as a demonstration of OO dogma... any thoughts?

Michael Rogers bastard_machine@hotmail.com

All programs run with your rights. They effectively setuid to the user. This is *BAD* (and inherently insecure).

Eros is immune to these flaws (which also affect all Unix systems).

BO is a trojan horse. If you can get a user to run an executeable, you have him fscked. If I send someone a Linux executeable which modifies his login script to start a telnet server (modified to not require a login, of course) on some non standard (>1024) port, he has his account wide open. Anything he can do, you can log in and do as well. Is this a security flaw of Linux?

You cannot prevent users from doing such things, under any OS. As such I think Microsoft is right that this is not really a security problem in Windows.

Windows NT does not have exceptionally bad security compared to other OSes. But in defense of the future of CS, trojans are a problem that needs to be solved.

Sandboxes (as in Java) are one attempt to solve this. They aren't a very good solution, but more of a hack on underlying security problems.

I think capability systems provide the sort of fine-grained access that is needed. Eros is an OS that attempts to do this. There are some papers online there about capabilities -- What is a Capability, Anyway? might be a place to start.

BO is a trojan horse. If you can get a user to run an executeable, you have him fscked. If I send someone a Linux executeable which modifies his login script to start a telnet server (modified to not require a login, of course) on some non standard (>1024) port, he has his account wide open. Anything he can do, you can log in and do as well. Is this a security flaw of Linux?

You cannot prevent users from doing such things, under any OS. As such I think Microsoft is right that this is not really a security problem in Windows.

Windows NT does not have exceptionally bad security compared to other OSes. But in defense of the future of CS, trojans are a problem that needs to be solved.

Sandboxes (as in Java) are one attempt to solve this. They aren't a very good solution, but more of a hack on underlying security problems.

I think capability systems provide the sort of fine-grained access that is needed. Eros is an OS that attempts to do this. There are some papers online there about capabilities -- What is a Capability, Anyway? might be a place to start.

Cool stuff like complete object persistance integrated with capabilities, total virtualization of memory (no "file system" per se) and a sorta microkernel architecture.

Like I said, Eros itself may not be the OS of the future, but a lot of the ideas contained therein will be widely used.