Slashdot Mirror

Before anyone jumps on the band wagon and says that we all have perfectly usable user space desktop apps for 28 years in the UNIX world, let me say that it is actually very important that now even Microsoft starts to understand that modularity is the way to go while designing complex systems. Moving various operating system components to the user space is just a logical conclusion of the research done during the last four decades. Look at the direction of modern OSii development, from MINIX to GNU. Started by GNOSIS, KeyKOS, EROS and Coyotos this trend seems to suggest that it is much more natural and reliable to design a secure capability-based system when all of the services are separated from each other. Now when even Microsoft is going in that direction - and it is not a trivial change for them, trust me - we can expect Apple and other OS vendors to follow which is a Good Thing. After all, even if people like you and me are using secure operating systems we still don't want to get spammed and dossed by all of the legacy machines out there. It turns out that the rumors that Microsoft is starting to take the latest research in operating systems seriously turned out to be true. This is good news for everyone.

Slashdot sucks when it's time to try to actually learn something instead of flaming and ranting and trying to one-up each other.

The principle of least privilege is the only known approach that might possibly lead to a secure operating system... what do we do in the US? Let the only project we have fall off into obscurity.

We then deride the EU when they actually decided it would be a good idea to try to fund a project with the possibility of success.

We need secure endpoints before we can ever hope to have a secure infrastructure. We're not smart enough to even try to pursue the only known approach that might work. We're doomed. Hopefully someone will understand this, not see it as a pure rant, and learn something.

--Mike--

Why not fund Coyotos ( http://www.coyotos.org/ ) or even CapROS ( http://www.capros.org/ ) instead of reinventing the wheel?

Funding is really what those projects are in need of. They already have working concepts.

There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence, but they are flat-out wrong:

Q: File system?

A: Nope. Sorry. Nobody needs files in Phantom. All the operating system state is saved across shutdowns. Phantom is the only global persistent OS in the world, AFAIK. All the state of all the objects is saved. Even power failure is not a problem, because of the unique Phantom's ability to store frequently its complete state on the disk.

To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:

At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.

Now one thing Novell is not is stupid. They refused.

Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.

Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.

Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.

Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.

The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.

If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:

• Coyotos, an OS whose orthogonal persistence falls out of the capability model of security that they embrace. Coyotos is written in BitC, a purpose-built high-level programming language with special focus on formal semantics and reasoning.
• Singularity, a language-based OS in development by none other than Microsoft Research. (Certainly the most interesting Microsoft project that I am aware of.) Singularity exploits language semantics to isolate processes.
• TUNES, a collective wet-dream of what the OS, programming language, and generally computing system of tomorrow should look like. With all due respect towards the insurmountable difficulty and endless complexity of a task like this, it must be said that TUNES is just vaporware.

Coyotos?

[they do get a lot of military funding, iirc.]

http://www.openbsd.org/

http://www.lynuxworks.com/solutions/security.php

http://www.coyotos.org/

It's actually linked in Andy's follow up of TFA, and written by the brilliant Jonathan Shapiro. He does miss the opportunity, however, to point out to Linus that address spaces need not be exclusive of each other, ie, data sharing is not so difficult to do in most microkernels.
http://www.coyotos.org/docs/misc/linus-rebuttal.html

A capability-based os (such as the following research project: http://www.coyotos.org/) *could* protect against a trojan such as this. The idea is that you only grant applications the capabilities necessary to perform their function *and nothing else*. On Windows/OSX/Linux, running a misbehaving word processor could potentially wipe every file your account has access to. In a capabilities based system, running a word processor would require you to explicitely allow it access to one file: the one you're about to edit. It would be unable to affect any other files on the system (until granted permission) or access the internet, etc.

So basically the instant you see your supposed 'video codec' try to access the internet, you know something is wrong and can deny it from having that capability. There's no way to shield a completely incompetent admin from themselves, but for those of us that have a clue, this would remove the trust we currently have to place in software publishers.

In the meantime, there's always vmware.

Sure, sessions will work for sites like forums. However, is there going to be anything shown by session length that won't be shown by page views in that case? What about pages that you can really spend days to weeks at a time staring at, such as the glibc manual or the Coyotos microkernel specification? If the user never refreshes the page before the end of the session, information-packed sites aren't going to be measured at all.

I would like to know whether RMS has a proposal for securing the internet, or if he considers it an important problem.

I think the answer is probably yes and it's probably an OS like GNU/Hurd (made of independant API servers) built on top of a mathematically proven microkernel like Coyotos.
http://coyotos.org/
http://en.wikipedia.org/w/index.php?title=Computer _security&oldid=89887507#Techniques_for_Creating_S ecure_Systems

As for TCPA/TCG/TPM being such a securing proposal, the answer is no.
You can't open the TPM chip in order to know if there are bugs or backdoors in it (security by obscurity).
Also, you can't update the wired cryptographic tools in the TPM to avoid new exploits or new cryptanalysis discoveries.
All softwares that are allowed to use the TPM, including the OS, won't become magically without bugs. A bad bug in those softwares (that are trusted by the TPM) can be used by an unauthorized person to manipulate the TPM and access its services like decryption of confidential data.

GNU/Hurd developers are commited to create THE best possible kernel. They don't have any time pressure so they can freely make experiments in the true spirit of Open Source.

Right now, there is an ongoing effort to use Coyotos ( http://coyotos.org/ ) to create the first operating system with the proved correctness of its kernel.

Besides, message-passing interfaces (the core feature of microkernels) can be potentially very efficiently implemented on multicore processors. For example, ARM Fast Address Space Switching (FASS) can potentially make microkernels FASTER than common monolythic ones.

As far as network drivers in particular go, the layers that use them, such as IP, live in the kernel, so it's rather annoying for them to talk to drivers that are up in user space. Specific network cards, especially wireless, might have bits that live up in user space, such as user interfaces for loading in crypto keys, but the bulk data transfer applications normally belong down in or near the kernel.

Why are there a whole pile of network card drivers in the kernel when you'd normally use only one or two? Same reason there are a whole pile of drivers for other devices in the kernel, when you've normally only got one graphics card and one sound card. If you're shipping a pre-compiled kernel, you want it to support as many different users as possible, and all it costs you is some RAM to store the code you're not using, or if you can handle them as loadable modules, it only costs you the work to keep track of those. But if you want to compile your own kernel for specific machines, and leave out the drivers you don't want, and while you're at it compile all your applications programs with the level of optimization your hardware supports, get a copy of Gentoo Linux and have fun learning lots more detail about Linux internals.

Coyotos is an attempt to do just that, led by Prof. Jonathan Shapiro who is a pretty smart cookie too.

Unfortunately it appears that GNU/Hurd will somehow be re-used as a run-time environment for Coyotos, so RMS may dodge the cream pie this time around :-)

I thought HURD switched over to the L4 microkernel. What gives?

Yeah, but think of where Linux would be if Linus was still working on it alone at home because it didnt quite have all of the features that he wanted.

We know exactly where it would be, because another open-source kernel project has succumbed to this.

The GNU kernel was originally meant to be based on Trix, but then it was decided that it was too much work to port to other architectures, so work began afresh on the HURD, based on the Mach microkernel. After a while, it was decided that Mach wasn't good enough, so work began again on a revision of the HURD, this time based on the L4 microkernel. These days, there's talk about abandoning that work too, in favour of something based on Coyotos.

Meanwhile, after sixteen years, GNU still don't have their own production-ready operating system kernel, but more pragmatic people have brought us Linux.

In fact, this is what the Coyotos project aims at. I'm sure there are others as well. What is interesting with Coyotos however is that they are implementing the kernel in a programming language (BitC) that allows them to formally verify security and correctness properties.

As others have pointed out, the proposed position is a PR position. I want the real deal -- actual security not the appearance of it. On that note, the clueless keep making noise about Unix being "fundamentally more secure" than Windows, and that's bullshit. Let's be clear: the practical differences between OS X and WinXP in terms of security come down to the vendor's practices and the dilligence of the admins. There's no technological magic juice here. There are, IMO, zero fundamental differences between OS X and WinXP (or stock Linux) when it comes to the potential for local or remote vulnerabilities. Local and remote exploits are quite possible and practical on all these platforms.

Thus Apple has two approaches it can take. First, it can consider tactics that harden the system as a whole, making it much harder for exploits to work in the first place. Look to approaches such as those taken by grsecurity, SELinux, and the other layers found in hardened Linux and *BSD distros for examples. Harden the hell out of the kernel and compiler layers as baseline approach. Perhaps fund Coyotos work as a strategic-term approach, with an eye towards migrating the kernel. The room for innovation here is to present a hardened system that isn't any harder to use.

Second, Apple simply must be dilligent in identifying and fixing exploits. To that end, I'd propose that Apple offer a substantial first-reporter bounty for local and remote exploits on the Mac OS X platform. Think about it: set aside the equivalent salary+overhead of one or more good security experts. Divvy that amount out to leverage a larger community each year. I'd love to see a few students help pay their way through college this way. 8-)

Forget the illusion of no exploits -- go out, find 'em, and close 'em first.

Re: Handle Security. You've just reinvented the wheel. Congratulations. Here's an example of an attempt to bring this model to the world of general-purpose computers: http://www.coyotos.org/

That sounds great and all, but do you have any idea of the complexity, and therefore cost involved? Ever tried to debug something consisting of 10000 lines, let alone something the size of an OS?

Interestingly there was just an article about exceptionally low defect rates for software, with cases running from a mere 10,000 up to almost 200,000 SLOC, all done for very reasonable time frames and costs. That, of course, is still signficantly less than the complexity of, say, the entire Linux kernel - but then no one said the whole thing had to be perfect, why not just start with the critical parts? Does it matter if every single obscure device driver is perfect? Under the circumstances that's forgivable, and porbably isn't so important. Making sure the core parts are exploit free using solid techniques does make some sense though. There are such projects underway - see Coyotos and Singularity.

a better goal is to ensure that when bugs are found they have minimal impact (like ensure users aren't running as root)

Indeed, but we can do better than this - there are more modern architectures for isolating problems, and they are available right now in Linux, SELinux being the most visible example. The problem is that right now applications often aren't written to respect, or take advantage of the benefits SELinux offers, so the improvement just isn't that great (a very loose policy is required). That is to say Linux is in a state with SELinux similar to where Windows is with Administrator accounts: the technology is there, and if used would represent a huge step in improving security, but because of lagging applications and users it's failing to take the required steps to e more secure.

Jedidiah.

The Coyotos project attempts to implement a full OS that can be mathematically proven safe and secure. It's actually quite a fascinating project; reading the mailing lists and watching BitC and Coyotos develop feels a bit like what it must've felt like to watch UNIX and C grow up in the 70s.

If someone sent a copy of this to Micro$oft? Would any of them read or comprehend it? It could make a difference in the version after Vista.

Oddly enough it would make perfect sense to some people at MS. The Singularity OS project from MS research uses a lot of the same ideas in development methodology and formalism. Whether Singularity will ever make it out of MS research, or simply remain a curious little side project, is of course an interesting and quite open question. Only time will tell.

For other OSs developed in a similar mold, try Coyotos which, while still getting seriously underway, looks quite promising indeed when it comes to secure and robust OSs.

Jedidiah.

• Limited-write-cycle devices, like thumbdrives. If "save after each byte" trashed the FAT table sectors of my shiny new 1GB USB drive, I'd have to beat someone.
• As someone else mentioned, network access. Few of the projects I work on are local to my own drive. I access most of them via SFTP or WebDAV, plus some NFS and Samba thrown in for good measure. I don't want my working file, regardless of how small, written out continually.

I don't think that "saving" is quite the high-level abstraction you're making it out to be, and it's shorter than saying "write contents to permanent storage". I don't see the concept of files going away any time soon, and as long as we have them, users will need to write to them.

In your defense, I don't think that using unsaved files as a convenient "undo buffer", as mentioned here by others, adds functionality that a good bookmarking system couldn't achieve (albeit with much greater overhead and fragility).

It will be interesting to see how long it will take the free software world to come up with something similar

As in "same design" or "reliable Operating System"? The later problem has been tackled already. As mentioned CoyotOS is currently considered the research OS for secure & reliable Operating Systems.

This is just a research OS written in C#.

No, it's written in Sing# which is an extension of Spec# which is an extension of C#. People really ought to pay more attention to Spec# - it's a nice extension of C# that allows for more formality if and when you require it. It's in the same class of language as SPARK which is an extension of Ada, JML which extends Java with specification semantics, BitC, Extended ML, HasCASL, and I guess to a lesser extent things like Eiffel and D.

Think of it this way: static types and type signatures for functions allow you to specify things about the software that the compiler can statically check and make sure there aren't any silly errors. The languages listed above (to varying degrees) allow for more exacting specification about the software, and hence you can (with the right tools) do far more comprehensive static checking and ensure various properties of the software. The difference is that, with most of these languages, the amount of specification is optional - you can be as exacting as you want where you need it, and not bother where you don't. It's like a dynamically typed language that lets you declare and use static types (and check them)just for those areas of code where it matters (except you start with static types and can provide more exacting specification where it matters). It's well worth checking out.

Jedidiah.

As far as I can see, the language in question is not exactly "new" anymore, being C#.

Actually its an extended version of Spec# which is in turn an extension of C#. It might help to acquaint yourself with what that actually means. The first significant different is that Spec# allows for explicit pre and post conditions and other formal specificiation syntax, and hence allows for model checking, extended static checking, and formal proof if required.

It's more like someone writing an OS in BitC because it can be formally verified and hence be more secure. It does make sense, and there is good logic behind it. Comparing it to an OS in Java is just silly. Comparing it to an OS written in Java using JML and associated theorem provers is getting a little closer. Of course that doesn't address the issue of designing the OS to be more secure and reliable from the outset, and not just relying on formal verification.

If you actually bothered to read some of the material on Singularity you would see that it is an ambitious, but remarkably interesting and promising project. It is also, I would expect, something that will permanently remain buried in MS research like so many other projects. I would be interested in seeing a good open source equivalent though - such a project might have some hope of surviving.

Jedidiah.

Better question: when's the last time anybody wrote an OS from scratch?

Let's see.. There's EROS and Coyotos, just to name two within the last decade.

-jcr

If, as you just said, you "stick to machine words" what does field reordering have to do with anything?

Because we're in a new century. I/O isn't performed one word at a time anymore:

Device command queues
Example struct for SCSA1394 (see scsa1394_cmd struct)

Field reordering breaks device communication.

But it says nothing about alignment, so even though its more predictable, its still completely useless.

And once again, as I've stated before, this is what pointer arithmetic is for. If you have alignment requirements, then you need a host-specific alignment-check. Yes, it's worse than Ada which can specify alignment portably. Unfortunately, Ada has other problems, but I've mentioned them before so I won't repeat myself.

Well, you can, but its completely unportable.

The number of non-portable features are small, and isolatable. Yes C forces you to do more work than other languages in this regard. Unfortunately, it's the only language with an implementation that has the other required features. Sucks, but there it is.

All those techniques yield competitive performance to C in user space. Why do you think they wouldn't do so in kernel space?

I'm speaking from the perspective of a microkernel when I'm arguing this, so perhaps that illuminates things for you. A small implementation with critical code paths that fits nicely within L1 cache are essential for high performance. Can you honestly tell me with a straight face that JITC techniques, garbage collection, and other high-level features are competitive with C for producing such code? Point me to a high-level language you think is usable in a kernel, ie. with all or some of your desired feature set, then show me where it gives you direct low-level control over memory layout and data structure representation, and control over the runtime.

The only efforts I've seen in this regard are BitC, Nitro, and Cyclone (projects that actually have implementations that is). None of them are there yet.

I don't think any of those systems will ever result in a practical OS; they were/are research projects.

I suggest you read more about the history of EROS. It was initially designed as a direct reimplementation of KeyKOS, the first commercial timesharing operating system to support mutually suspicious clients. It's been used in ATMs and other mission-critical operations for decades. EROS has since improved on the KeyKOS design. There is absolutely no reason why CapROS could not become a practical system. There is nothing research-centric about EROS/CapROS except its unfinished nature.

I agree with that definition of microkernel, but "Salamander" apparently does not.

I'm sure he agrees with that definition, but he's disagreeing with your assertions that the kernel as a managed virtual machine of some sort would be more practical and useful. While potentially an interesting direction for research, it does not at all seem feasible with current hardware. Well, current consumer hardware; high-end architectures have more exotic features which may make it possible.

Like it or not, hardware page-level protection is the best we have, and microkernels are thus far the best way of exploiting this widely deployed architecture. Fortunately, page-level protection really is good enough for every purpose we need. In particular see CapROS and Coyotos for pure object-oriented operating systems (Actors message-passing syle with true capability security). I think you'll learn a lot from the papers written on EROS/CapROS.

It sounds to me increasingly like "microkernel" to you means "a kernel implemented in ANSI C that uses a hand-crafted message passing object system".

Not necessarily C, but any low-level language that gives the programmer direct control over representation and runtime (this is the only real requirement). So why not C++, or BitC?

The defining characteristic of microkernels is a small set of kernel-implemented primitives upon which an entire system can be built in userspace. EROS/CapROS, and Coyotos have only one system call and a few kernel objects for instance.

The biggest problem seems to be that that extra layer of abstraction slows things down (which makes sense really). [...] If heavy usage servers can be run as virtual machines in Xen then why not use a microkernel too?

Funny you should mention Xen, because it's essentially a microkernel running other kernels as protected processes.

So. Any examples of microkernel OS's that handle heavy server load, function well as a desktop, and can handle multimedia tasks like gaming?

Other posts mention QNX, so I won't bother.

I'd find it hard to believe that with solid numbers showing that microkernel is just as fast and without additional overhead that someone like Linus wouldn't use it since it's an easier programming model (better for security, stability, etc).

You'd be surprised. There's a lot of vested interest in the current programming paradigms and existing codebase. A principled microkernel architecture might just be incompatible with POSIX, which eliminates a large swath of portable and useful software.

If you want performance, you need look no further than L4, EROS (and it's successor CapROS). For a principled design, I'd go with EROS/CapROS or the next generation capability system Coyotos (who's designers are trying very hard to implement POSIX while maintaining capability security).

Something useful right now, doesn't exist as far as I know.

But such fine-grained controls are incredibly tedious

Hogwash. The grsecurity patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.

With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.

It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ and its predecessor http://www.eros-os.org/ for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.

It's a daunting task, but damn well worth the effort IMO.

You are wrong. Perhaps a provably secure Linux is impossible. But Alan Cox didn't say "operating system." He said, "system." Always pause (at least briefly) before suggesting that you have a better understanding of operating systems than Alan Cox.

These guys are working on just such a concept, attempting to write a microkernel OS in a language that supports formal semantics amenable to verification and correctness proofs. It seems they are still just getting underway, but it looks like an interesting project.

Of course this will not guarantee 100% security because "secure" is a rather loose term and will mean more than just a kernel that doesn't have any buffer overflows or other bugs. They will be able to, however, tell you very precisely what exploits and attacks the system is definitely secure from, which would be quite a significant step forward.

Jedidiah.

There's people working on that stuff now. Check out Coyotos for information on the BitC programming language.

Without attacks and threats we wouldn't bother developing a resilient software ecology. Heck, we're still not there despite mounting attacks. We would only have the illusion of privacy at best.

Security and software is an ecology, and we have to evolve appropriate measure to combat attacks. The techniques are here [1][2][3][4], we just have to deploy them.

[1] EROS
[2] CapROS (EROS development moving to the community)
[3] Coyotos (EROS successor in the research communits)
[4] E: secure, distributed programming language

For these really different systems you point to, RELIABILITY is also a key point (and closely related to security). You think >1 year uptime for a BSD box chugging away in a basement is good? How about 17 years uptime? And that's when they pulled the plug, not when it died.

I think for really secure + reliable designs you should look at micro-kernel based systems like L4Linux or Gnu's HURD (also moving towards L4). Note: not saying these systems are ready now, because they're still under development, and may have a long way to go before they're 'done'.

Linux is somewhat ahead in this in that protected memory is part of its "DNA", unlike Windows which ultimately comes from the culture of DOS, which has no protected memory and is not multi-user.

But still, Linux is only just a little bit better. We need to move to real secure designs such as:

• Coyotos
• Jnode
• SE Linux (already incorporated in Fedora)
• EROS - has now become Coyotos, above

Are you saying this has been done? Multics had better buffer overflow protection

40 F#%îng years ago! thats right, *before unix existed*, four decades ago, thats before gates had pubic hair! (Okey, I didn`t fact check that one, but this is a long time, and I am not just talking in Internet or doggy years.)

So, where are the lines before compusa to buy one of these computers that may not have the most megahurts and marchitecture, but that doesn`t get new viruses/spyware/script kiddy zombie code every week while mailing personal files to random strangers?

I will tell you where these people are, they are right around the corner at the newsstand waiting for the latest issue of "screenshots, colors, windows and screensavers monthly". While there are billion dollar (memory) price fixing and (os) monopoly scams going on the trade media wonders what the color of Microsoft's next operating system is and where to get the newest megahurts this month....

The reason multics was secure, the people designing it figured security would make a nice feature so the designed it in by default... Ofcourse others tried that but once you add a huge piece of shell/browser/e-mail client/media player, mix in a bunch of rpc accesible administrative tools and have all this code monkey C code run with administrative privileges.... then you are gonna need systems to tell you when your remaining security is gone. (virus signature addiction systems, packet filters and intrusion detection systems).

The babysteps taken in todays "security addons" that descent from the tools dos admins used to clean out the few know viruses are pathetic. The worst part, the people making money of it. These people are evil even by atheist standards (keeping people addicted to virus signatures while selling telephone tapping equipment by comverse/the mossad, while playing "trusted" third party by selling expensive cert`s (Want a microsoft.com one? here go right ahead).... while screwing everyones DNS over just for a few quick bucks. )

The people selling computer security are snakeoil/ducttape sales scumbags

If people had just read the US DoD stuff on computer security (multics, orange book) and used it as a starting point for a one step more secure OS we could just worry about how to make computer do new usefull stuff instead of fending of the spyware/worms/ddos and god knows what people who stay out of log files do. Anyway, one can always start from scratch

Until things start getting fixed at the tool and OS level we're going to continue having these types of exploits once a month for the NEXT twenty years. If we don't switch from using C this is going to be the Slashdot headline in 2025: "Vulnerability on Microsoft HoloChat allows attackers to take over your nervous system."

Since it's object-based, the natural storage model is persistent objects, and EROS and its relatives spend a lot of time making sure they stay persistent, e.g. syncing them to disk when needed - they tend to not mind if you do things like unplugging the power cord while processes are running, and start right where they left off when you plug them back in. On the other hand, the storage models aren't what you're used to unless somebody's written an emulation layer on top of it, and the emulations may also be different than what you're expecting.

Probably: yes. My feeling is that orthogonal persistance and extreme reliability (2 goals of the EROS project) are conflicting goals.

Orthogonal persistance is very useful from a user point of view: you don't need to 'save' files, you don't need to 'close' apps, so noobs can't forget it. Application programmers don't need to worry about closing files, there's just a state of the app that's saved in regular intervals, transparently done by the OS.

But the other goal, extreme reliability, requires something else: extreme simplicity of some aspects/components of the OS. If you introduce too much complexity, the extreme reliability goes out the door.

My guess is that EROS has shown that you can't have both as a core feature, and that you are forced to choose: drop the extreme reliability, or move the persistance feature out of the core into another layer (like do it an application level). It seems that developers have chosen the latter, to preserve reliability as a core feature. IMO a good choice: persistance may be a nice thing to have, but no good to use it everywhere. The project history explains this some more.

First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

Not necessarily. Both EROS and L4 have no knowledge of the disks in the kernel proper, yet both support transparent orthogonal persistence. Only knowledge of the memory mapping structures are needed, and the kernel needs to know of those anyway.

More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever.

Until the software crashes or is killed. Then you restart the service. No different from a regular system.

OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

Incidentally, both EROS and Coyotos support exactly what you suggest. Each IPC is an implicit transaction, execution contexts are extremely lightweight, and communication is blazingly fast.

See the Coyotos history page for a discussion of the properties of Coyotos. Or check out Towards a Verified, General-Purpose Operating System Kernel on the docs page

First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

Not necessarily. Both EROS and L4 have no knowledge of the disks in the kernel proper, yet both support transparent orthogonal persistence. Only knowledge of the memory mapping structures are needed, and the kernel needs to know of those anyway.

More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever.

Until the software crashes or is killed. Then you restart the service. No different from a regular system.

OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

Incidentally, both EROS and Coyotos support exactly what you suggest. Each IPC is an implicit transaction, execution contexts are extremely lightweight, and communication is blazingly fast.

See the Coyotos history page for a discussion of the properties of Coyotos. Or check out Towards a Verified, General-Purpose Operating System Kernel on the docs page

First, if you put "persistence" in the OS, the OS has to know about disks, which, otherwise, a microkernel does not.

Not necessarily. Both EROS and L4 have no knowledge of the disks in the kernel proper, yet both support transparent orthogonal persistence. Only knowledge of the memory mapping structures are needed, and the kernel needs to know of those anyway.

More significantly, "persistence" means keeping your mistakes around. Memory leaks are forever.

Until the software crashes or is killed. Then you restart the service. No different from a regular system.

OS design needs to go in the other direction, that of efficient transaction processing, where execution environments are created, used, and quickly flushed. That's better from a security and reliability standpoint.

Incidentally, both EROS and Coyotos support exactly what you suggest. Each IPC is an implicit transaction, execution contexts are extremely lightweight, and communication is blazingly fast.

See the Coyotos history page for a discussion of the properties of Coyotos. Or check out Towards a Verified, General-Purpose Operating System Kernel on the docs page

Check the history, they're getting rid of persistence in Coyotos...they want to make it posix-compatible and more familiar to people. The other big change is writing the whole thing in BitC, using patterns that allow security proofs on the entire kernal: "If we are successful, we will produce the first general-purpose operating system and utility set with end-to-end verification of security and correctness properties that extends all the way through to the code."

There is a discussion on coyotos-dev at the moment about the decision to remove persistence; it's entirely possible that it will be reversed. Subscribe if you have an interest in this (but read the archive of the thread first).

There is no direct historical relation between Multics and EROS. See The Path to Coyotos. Multics is not even capability-based, and doesn't even appear on the map of capability computation which shows the development history proceeding from Hydra, to Gnosis/KeyKOS and ending at EROS.

Which one will it be the first to procure the secured operating system?

IEEE BOSS

or

Coyote OS

My money is on Coyote.