Crypto is an essential feature, but crypto isn't novel. The hard problem in crypto is having a safe place to run it. Nothing on your web site describes how you achieve this.
What formal model? Where is it published? What formal specification language was used? Exokernel is anything but a proven model in formal terms. Indeed it may not be possible to model it formally.
The assertion that "resource management is handled" is often made but seldom honored. Where is the design for this agent published? Central agents generally imply covert channels. Given the choice of a central agent design, how are covert channels to be limited?
If the design has not been publicly reviewed, your claims of security are only that: claims. I sincerely hope they are right, but in the absence of a public design you have not offered a convincing argument. In contrast, people have been picking on our stuff for *years* without finding a substantive hole. I don't say this is the only way to go, but it is a very very helpful way to go.
Any crypto system is now allowed in the US so long as it is (a) open source or (b) commodity. In any case, the design is not encumbered. Secret crypto is invariably broken crypto.
The phrase "too sensitive to publish" sounds suspiciously like "not solid enough to withstand criticism." If you must, patent it first, but offer it for public review. Your mere allegation that something is wonderful does not make it so.
I look forward to a time when you disclose enough for your claims to be examined and accepted or refuted. Until then, it's all unsupported allegations. When your website has been updated, please let me know. I'ld like to take a look.
Kaos may well be interesting someday, but right now there isn't enough on the website to understand what it is trying to do. I'm skeptical, for several reasons:
Crypto isn't the solution. Crypto isn't the problem. Crypto is only as good as the OS it runs on. Information flow and resource denial are the problems.
When you can show a formal model (hell, even a credible argument) for how you can utterly prevent one program from tampering with another, you are ready to begin building a secure OS. Until then, don't cut code -- you aren't ready yet.
Similarly, you need a solution and a compelling design that deals with resource denial of service.
BSD (and other UNIX derivatives) aren't a viable starting point. See (2,3).
So far, the website has lots of buzzwords, but neither design docs nor code. I really encourage you to persue Kaos, but what you are trying is a long hard haul. Lots of people have tried to do what we are doing. Mostly, their gone and we're still here. I would welcome competition in the secure system space -- it would benefit all of us by raising overall credibility.
Hmm. As I reread, this note seems harsh, even though I don't mean it to be. Still, I think the points are valid. Good luck with Kaos.
For anybody who is interested in EROS, we expect to finally hit the point where people can start building app code in the next month or two. When that occurs I'll try to figure out how to post a slashdot announcement. It's always better when people can try it for themselves and get a sense of the strengths and weaknesses of a new system.
Though I must say, the conversations on the cap-talk list have been pretty cool lately -- Eric Raymond, Alan Cox, Mark Miller, John Randolph, and I have been trying to figure out how far we can go to rescue UNIX apps in a fundamentally secure environment. Succeed or fail, the process of thinking things out is turning out to be pretty interesting.
Here's a stupid question, but what the hell, maybe somebody has done it:
Has anybody considered doing a SPARC-on-LINUX user-mode emulation coupled with a Solaris personality? It won't help this guy, but technically it's not that hard.
Oops. I got my version numbers mixed up. The version we skipped was the 1.0 version. 2.0 Will be the embeddable microkernel version.
A curious thing relative to OPPCOS: the EROS group decided to move orthogonal persistence back out of the kernel along with drivers, because (a) once the drivers are out, persistence pretty much has to go out as well, and (b) embedded systems often don't want it, or want explicit persistence management.
There are a lot of effects that could account for these results. Some are significant, some are coincidental. I agree these numbers are pretty appalling -- simple programs ought to work well -- but it is also striking that Ed's benchmarks don't seem to reflect any knowledge of standard OS microbenchmark suites. Larry McVoy put a lot of attention into measurement methods in the lmbench suite that the article could benefit from.
The EROS site is at http://www.eros-os.org. Some related stuff that I'm working on can be found at http://srl.cs.jhu.edu
For a variety of reasons, we decided not to do a real release of the 2.x series of the kernel, because it became clear that another round of kernel architecture changes would be needed to adequately support embedding and real time. We've been hard at work on that, and the currency of the web site has suffered as a result. To give you a sense, the kernel has shrunk over 200k since the pre-2.0 non-release and is still shrinking.
In fact, sometime in the next few weeks we expect to pass a significant milestone: commands typed at a (pretty dumb) shell. At that point we'll have the component model pretty well solid, and can start in on application-level work seriously.
As to OPPCOS, it has no relationship to EROS. I went so far as to haul down the tarball and take a brief look. It's not clear to me what their plan is. There is no documentation, which makes it hard to discern where they are going. Hopefully, they will put some up soon.
The big news about EROS recently is that we received some significant funding from DARPA to get a secure web client going, and that in the process we are going to be able to build up most of a reasonable user environment.
For those who are interested to keep track, make sure that you are on the eros-announce list. You can subscribe at http://www.eros-os.org/mailman/listinfo.
Slashdot Mirror
Todd Fries just submitted the patches getting OpenCM to build under OpenBSD. They'll be included in the next alpha.
Crypto is an essential feature, but crypto isn't novel. The hard problem in crypto is having a safe place to run it. Nothing on your web site describes how you achieve this.
What formal model? Where is it published? What formal specification language was used? Exokernel is anything but a proven model in formal terms. Indeed it may not be possible to model it formally.
The assertion that "resource management is handled" is often made but seldom honored. Where is the design for this agent published? Central agents generally imply covert channels. Given the choice of a central agent design, how are covert channels to be limited?
If the design has not been publicly reviewed, your claims of security are only that: claims. I sincerely hope they are right, but in the absence of a public design you have not offered a convincing argument. In contrast, people have been picking on our stuff for *years* without finding a substantive hole. I don't say this is the only way to go, but it is a very very helpful way to go.
Any crypto system is now allowed in the US so long as it is (a) open source or (b) commodity. In any case, the design is not encumbered. Secret crypto is invariably broken crypto.
The phrase "too sensitive to publish" sounds suspiciously like "not solid enough to withstand criticism." If you must, patent it first, but offer it for public review. Your mere allegation that something is wonderful does not make it so.
I look forward to a time when you disclose enough for your claims to be examined and accepted or refuted. Until then, it's all unsupported allegations. When your website has been updated, please let me know. I'ld like to take a look.
Kaos may well be interesting someday, but right now there isn't enough on the website to understand what it is trying to do. I'm skeptical, for several reasons:
Crypto isn't the solution. Crypto isn't the problem. Crypto is only as good as the OS it runs on. Information flow and resource denial are the problems.
When you can show a formal model (hell, even a credible argument) for how you can utterly prevent one program from tampering with another, you are ready to begin building a secure OS. Until then, don't cut code -- you aren't ready yet.
Similarly, you need a solution and a compelling design that deals with resource denial of service.
BSD (and other UNIX derivatives) aren't a viable starting point. See (2,3).
So far, the website has lots of buzzwords, but neither design docs nor code. I really encourage you to persue Kaos, but what you are trying is a long hard haul. Lots of people have tried to do what we are doing. Mostly, their gone and we're still here. I would welcome competition in the secure system space -- it would benefit all of us by raising overall credibility.
Hmm. As I reread, this note seems harsh, even though I don't mean it to be. Still, I think the points are valid. Good luck with Kaos.
Though I must say, the conversations on the cap-talk list have been pretty cool lately -- Eric Raymond, Alan Cox, Mark Miller, John Randolph, and I have been trying to figure out how far we can go to rescue UNIX apps in a fundamentally secure environment. Succeed or fail, the process of thinking things out is turning out to be pretty interesting.
Here's a stupid question, but what the hell, maybe somebody has done it:
Has anybody considered doing a SPARC-on-LINUX user-mode emulation coupled with a Solaris personality? It won't help this guy, but technically it's not that hard.
Oops. I got my version numbers mixed up. The version we skipped was the 1.0 version. 2.0 Will be the embeddable microkernel version.
A curious thing relative to OPPCOS: the EROS group decided to move orthogonal persistence back out of the kernel along with drivers, because (a) once the drivers are out, persistence pretty much has to go out as well, and (b) embedded systems often don't want it, or want explicit persistence management.
Regards,
Jonathan S. Shapiro
(The EROS Guy)
There are a lot of effects that could account for these results. Some are significant, some are coincidental. I agree these numbers are pretty appalling -- simple programs ought to work well -- but it is also striking that Ed's benchmarks don't seem to reflect any knowledge of standard OS microbenchmark suites. Larry McVoy put a lot of attention into measurement methods in the lmbench suite that the article could benefit from.
Regards,
Jonathan S. Shapiro
(The EROS Guy)
EROS is alive and well, thanks.
The EROS site is at http://www.eros-os.org. Some related stuff that I'm working on can be found at http://srl.cs.jhu.edu
For a variety of reasons, we decided not to do a real release of the 2.x series of the kernel, because it became clear that another round of kernel architecture changes would be needed to adequately support embedding and real time. We've been hard at work on that, and the currency of the web site has suffered as a result. To give you a sense, the kernel has shrunk over 200k since the pre-2.0 non-release and is still shrinking.
In fact, sometime in the next few weeks we expect to pass a significant milestone: commands typed at a (pretty dumb) shell. At that point we'll have the component model pretty well solid, and can start in on application-level work seriously.
As to OPPCOS, it has no relationship to EROS. I went so far as to haul down the tarball and take a brief look. It's not clear to me what their plan is. There is no documentation, which makes it hard to discern where they are going. Hopefully, they will put some up soon.
The big news about EROS recently is that we received some significant funding from DARPA to get a secure web client going, and that in the process we are going to be able to build up most of a reasonable user environment.
For those who are interested to keep track, make sure that you are on the eros-announce list. You can subscribe at http://www.eros-os.org/mailman/listinfo.
Regards,
Jonathan S. Shapiro
(The EROS Guy)
EROS Architect