Singularity ideas
ad...@new-me.cn
features around this as can be seen in A Lightweight Method for
Building Reliable Operating Systems Despite Unreliable Device Drivers
and i note SIngularity has similar ideas but they take it further by
trusting save languages.
Is it worth implementing something like Singularity where you can run
a safe language (Java/C#) you can run the process at the same level at
the Kernel and not occur the heavy overhead context switch ,they are
showing a 33% performance gain for a typical benchmark which is
significant (29% if you turn hardware protection on but have the OS
and process on the same level) . L3 backs this up getPid takes 150
cycles almost 2/3 of which are for the switch . Obviously you can
configure this so when you develop the runtime you can benefit from
the protection durring testing and debugging.
I dont see any reason why the memory management of a runtime cannot be
trusted when the kernel can , making sure the garbage collection is
mature is no different than say a page manager ( espeically if the
runtime itself does not use pointers except where neccessary as this
reduces the size of the unsafe code).
With device drivers it is even more interesting they run device
drivers as user processes since they are written as safe language code
and precompiled and these run at the same hardware level as the OS .
Device drivers dont talk direct to the hardware they talk to a HAL in
the Kernel which handles DMA and IO . As DMA and IO are where a lot
of mistakes are with device drivers moving them to the kernel and only
allowing access via an API is not a bad idea. C/C++ Device drivers
can be run in the same user mode but at ring 3 instead of ring 0 and
incur the performance penalty..
Regards,
Ben
Jens de Smit
One of the design paradigms is to minimize the amount of code that
runs in privileged mode and being able to handle problems run time.
Singularity goes just the other way by trying to make absolutely
completely sure that no buggy code can enter ring 0. This is,
conceptually, not much different from a monolithic kernel, with the
exception that they try harder to prevent bugs by being more
restrictive as to what enters the kernel. However, you're basing a
huge trust on a large codebase. Any bug in a compiler, loader, linker
or analysis tool will eventually lead to a very nasty failure in ring
0. Add to that fact that I don't think static analysis can catch each
and every problem... I don't think this is such a tremendous idea. In
practice, this approach will probably prevent a lot of bugs and
thereby problems, but not all.
Oh, do you have a source for the performance gain?
Regards,
Jens
Matej Kosik
Their TCB is (according to my information) larger than 100000 lines of code.
http://www.osnews.com/thread?337733
This is one problem.
> Any bug in a compiler, loader, linker
> or analysis tool will eventually lead to a very nasty failure in ring
> 0.
Like in Minix. Minix kernel is also compiled by an unverified compiler.
Just like Singularity.
Not to mention the fact that both Minix and Singularity run on
unverified hardware. That sounds like an infinite regress, I fear.
> Add to that fact that I don't think static analysis can catch each
> and every problem... I don't think this is such a tremendous idea. In
> practice, this approach will probably prevent a lot of bugs and
> thereby problems, but not all.
I think you are simplifying things here. They rely on security
mechanisms beyond simple typechecker (such as reference monitor that
enforces security policies specified in "manifest" of a given component
etc).
Jens de Smit
> > or analysis tool will eventually lead to a very nasty failure in ring
> > 0.
>
> Like in Minix. Minix kernel is also compiled by an unverified compiler.
> Just like Singularity.
easier than verifying the result of 100000. I'd say the former is
actually feasible, the latter is not. Moreover, Minix is compiled on a
specific compiler from a specific manufacturer that has been stable
for what, 20 years, more? Singularity drivers will come from third
party vendors, compiled on any compiler, delivered as a binary. Hard
to guarantee that it's "good".
> Not to mention the fact that both Minix and Singularity run on
> unverified hardware. That sounds like an infinite regress, I fear.
between Minix and Singularity. If they run on the same hardware,
chances of hardware failure are equal.
> > Add to that fact that I don't think static analysis can catch each
> > and every problem... I don't think this is such a tremendous idea. In
> > practice, this approach will probably prevent a lot of bugs and
> > thereby problems, but not all.
>
> I think you are simplifying things here. They rely on security
> mechanisms beyond simple typechecker (such as reference monitor that
> enforces security policies specified in "manifest" of a given component
> etc).
don't think it's possible to catch all bugs before running into them,
especially not if performance is one of your goals (dynamic analysis
is expensive). If you run into a bug in ring 0, you can kiss your OS
goodbye and wait for the reboot. Valuing performance over reliability
is a choice, I was just trying to explain how that choice does not fit
well with Minix.
Regards,
Jens
Antoine Leca
>>> Any bug in a compiler, loader, linker or analysis tool will
>>> eventually lead to a very nasty failure in ring 0.
>> Like in Minix. Minix kernel is also compiled by an unverified compiler.
>> Just like Singularity.
>
> True, but verifying the resulting assembly code of 5000 lines is a lot
> easier than verifying the result of 100000.
Yes. And when the line count would be actualized for 3.1.4 (6,000?
8,000? without forgetting the kernel libraries ;-)), it will still hold.
> I'd say the former is actually feasible, the latter is not.
But it still is a LOT of work (that should be done entirely on every
build you want to verify.)
Furthermore, Minix 3 consists of more than the small kernel, as the
thread about "effort needed..." shows; sure, drivers have been put off
the path (and it certainly is a Good Thing), but there are still a lot
of things beyond the kernel required to make Minix minimally functional,
including but not limited to pm, rs, vfs, mfs, vm; they do not run at
ring 0, but they do have easy (and not throughly checked) access to the
ring 0 primitives and structures.
> Moreover, Minix is compiled on a specific compiler from a specific
> manufacturer that has been stable for what, 20 years, more?
Probably a bit less.
First, around 1991 (after 1.5) the hot thing around Minix was the "new"
C compiler (there are still traces of this "newness", for example the n
--for "new"-- in ncg; of course the front end was a substantial rewrite,
for ANSI compatibility; also, the i386 back-end did not exist before
1991-92, http://groups.google.com/groups?selm=13...@star.cs.vu.nl.)
And while it was not substantially altered after 1994 (according to the
CVS tags), we do not have the former history available to track back to
the earlier asld's of Minix 1.0-1.5 compilers of the 1983-87-89 vintage.
Furthermore, while this compiler is /stable/, the same can be said for
CvW's C386 or Bruce Evans' bcc of the same timeframe: in fact they had
not evolved and were not used for many projects, which is /not/ a good
thing when it comes about safety; Microsoft's C compiler (not the C++
one, much less C#) has also been quite "stable" for the same timeframe
as ACK, yet it also have been used widely and so probably it is more
solid when it comes to security or safety analysis.
Antoine
ad...@new-me.cn
> One of the design paradigms is to minimize the amount of code that
> runs in privileged mode and being able to handle problems run time.
> Singularity goes just the other way by trying to make absolutely
> completely sure that no buggy code can enter ring 0.
> This is,
> conceptually, not much different from a monolithic kernel, with the
> exception that they try harder to prevent bugs by being more
> restrictive as to what enters the kernel. However, you're basing a
> huge trust on a large codebase. Any bug in a compiler, loader, linker
> or analysis tool will eventually lead to a very nasty failure in ring
> 0.
untrusted/unverified kernel . And since Singularity has a 1 ownership
page , 1 app rule verifying things in memory is pretty easy. They
also have some protection for device drivers as they are written in
managed code only.
I have queried with them why the memory/page manager is in the Kernel
as i see no reason for it being there and can be accessed via
messenges instead of a kernel API.
>Add to that fact that I don't think static analysis can catch each
> and every problem... I don't think this is such a tremendous idea. In
> practice, this approach will probably prevent a lot of bugs and
> thereby problems, but not all.
with mature compilers which is what you said anyway.
I think they are still debating it as well ( hence the tests) and note
they do have the abbility to turn it on. ( Including putting user apps
in the same domain as they are assured to not touch the same
pages) .
Reliability
Monolithic ( Linux/Windows) << Singularity << Singularity ( with
prot) <= Minux. ( equal ? Singularity has a bigger code base but i
think there driver model is better via a HAL and driver bugs are
nasty)
Performance
Singularity >> Monolihtic (Linux/Windows) >> Minux /Singularity with
protection
The performance result is very interesting as this was the big
Monolithic argument and Singularity is pretty raw and unoptimized
>
> Oh, do you have a source for the performance gain?
>
Galen C. Hunt and James R. Larus one of the 5 papers you down load
with Singularity
WebFiles was the benchmark
Removing run time checks also gives them 4,7% more
Tyrning on 4K protected paging 6.3% penalty
Add seperate domain +18.9% penalty
Add ring 3 +33% penalty
Full micro kernel 37.7%
Note webfiles uses lots of content switching as it models a web server
with many connections.
Also cost is
CPU cycles
API call Thread Yield Message ping/
pong Process Creastion
Singularity 80 365
1,040 388,000
FreeBSD 878 911
13,300 1,030,000
Linux 434 906
5,800 719,000
Windows 627 753
6,340 5,380,000
Regards,
Ben
ad...@new-me.cn
> Their TCB is (according to my information) larger than 100000 lines of code.http://www.osnews.com/thread?337733
> This is one problem.
Sounds about right . I did query them why the memory manager was in
the Kernel . Also note the TCB includes the managed runtime GC. Also
modern C# code requires more lines than C/C++ and they have lots of
attributes and small methods. ( this one is to force inlining of
Kernel code) , lots of this stuff.
[Inline]
private static UIntPtr SpaceToAlign(UIntPtr data, UIntPtr
size)
{
return Pad(data, size) - data;
}
[Inline]
private static UIntPtr SpaceNotAligned(UIntPtr data, UIntPtr
size)
{
return ((data) & (size - 1));
> > Any bug in a compiler, loader, linker
> > or analysis tool will eventually lead to a very nasty failure in ring
> > 0.
>
> Like in Minix. Minix kernel is also compiled by an unverified compiler.
> Just like Singularity.
>
> Not to mention the fact that both Minix and Singularity run on
> unverified hardware. That sounds like an infinite regress, I fear.
fault . Still if these occur in a device driver you are in trouble.
>
> > Add to that fact that I don't think static analysis can catch each
> > and every problem... I don't think this is such a tremendous idea. In
> > practice, this approach will probably prevent a lot of bugs and
> > thereby problems, but not all.
>
> I think you are simplifying things here. They rely on security
> mechanisms beyond simple typechecker (such as reference monitor that
> enforces security policies specified in "manifest" of a given component
> etc).
ad...@new-me.cn
> But it still is a LOT of work (that should be done entirely on every
> build you want to verify.)
>
> Furthermore, Minix 3 consists of more than the small kernel, as the
> thread about "effort needed..." shows; sure, drivers have been put off
> the path (and it certainly is a Good Thing), but there are still a lot
> of things beyond the kernel required to make Minix minimally functional,
> including but not limited to pm, rs, vfs, mfs, vm; they do not run at
> ring 0, but they do have easy (and not throughly checked) access to the
> ring 0 primitives and structures.
Singularity.
>
> > Moreover, Minix is compiled on a specific compiler from a specific
> > manufacturer that has been stable for what, 20 years, more?
>
> First, around 1991 (after 1.5) the hot thing around Minix was the "new"
> C compiler (there are still traces of this "newness", for example the n
> --for "new"-- in ncg; of course the front end was a substantial rewrite,
> for ANSI compatibility; also, the i386 back-end did not exist before
> 1991-92, http://groups.google.com/groups?selm=13...@star.cs.vu.nl.)
>
> And while it was not substantially altered after 1994 (according to the
> CVS tags), we do not have the former history available to track back to
> the earlier asld's of Minix 1.0-1.5 compilers of the 1983-87-89 vintage.
>
> Furthermore, while this compiler is /stable/, the same can be said for
> CvW's C386 or Bruce Evans' bcc of the same timeframe: in fact they had
> not evolved and were not used for many projects, which is /not/ a good
> thing when it comes about safety; Microsoft's C compiler (not the C++
> one, much less C#) has also been quite "stable" for the same timeframe
> as ACK, yet it also have been used widely and so probably it is more
> solid when it comes to security or safety analysis.
say its quite new considering the compilations supports ARM as well.
They use the Bartok compiler not the standard C#.
http://en.wikipedia.org/wiki/Bartok_%28compiler%29.
I think we should consider the good ideas of Singularity its a
Research OS , so will never be released and will never mature but
Rumours are MS are developing a real OS based on this which will power
at first Windows Mobile 8 .
The best ideas i think are
- pages can only be owned by 1 process. ( Though multiple readers are
supported)
- Messages are strongly typed.
- Messages pass references , once passed the receiver now owns that
memory. Hence they still have 1 owner for 1 piece of memory.
- Managed code can run at the same level as the Kernel.
- Device drivers access everything via the HAL and run managed code.
( and run at the same ring as the OS and managed apps)
Matej Kosik
> Hi Jens,
>
>> One of the design paradigms is to minimize the amount of code that
>> runs in privileged mode and being able to handle problems run time.
>> Singularity goes just the other way by trying to make absolutely
>> completely sure that no buggy code can enter ring 0.
>> This is,
>> conceptually, not much different from a monolithic kernel, with the
>> exception that they try harder to prevent bugs by being more
>> restrictive as to what enters the kernel. However, you're basing a
>> huge trust on a large codebase. Any bug in a compiler, loader, linker
>> or analysis tool will eventually lead to a very nasty failure in ring
>> 0.
>
> True but monolithic kernels live with these things + a very large
> untrusted/unverified kernel .
I do not think that this is a good argument. Linux is reliable but at
what price (counted in human centuries). How many projects will have the
luck of attracting as many "eyeballs"? Also, Windows is more or less
reliable (I believe) but at what price? How many projects can afford to
pay that price?
Whenever when you are considering whether or not you are going to trust
ultimately to someone, it is wise to verify its reputation. Reputation
of authors of Linux and reputation of authors of Windows is quite different.
I do not aggree with Jens that language-based approach is hopeless but
in the context of Singuarlity, this discussion is irrelevant. It might
be interesting in case if:
- a given system has small TCB
- a given system has simple and powerful security model
- a given system follows principle of the least authority (POLA)
(which should not be confused with POLP---permission/privilege
and authority are two separate concepts)
- a given system has proper structure
(minimized dependency relationship)
I do not think that Singularity has any of these.
Matej Kosik
Jens de Smit wrote:
> Add to that fact that I don't think static analysis can catch each
> and every problem.
This statement significantly underestimates for example type system
described here:
http://www.springer.com/computer/programming/book/978-3-540-20854-9
The authors describe a type system (and other things) that can be used
for some of those things you think are not possible to do. It is a tough
book but I think worth reading. It describes a fancy typesystem that can
be used for (if I exaggerate) "catching each and every problem".
Certainly many of those you wouldn't imagine that can be catched by a
typesystem.
Sys Admin
>bklo...@gmail.com wrote:
>> Hi Jens,
>>
>>> One of the design paradigms is to minimize the amount of code that
>>> runs in privileged mode and being able to handle problems run time.
>>> Singularity goes just the other way by trying to make absolutely
>>> completely sure that no buggy code can enter ring 0.
>>> This is,
>>> conceptually, not much different from a monolithic kernel, with the
>>> exception that they try harder to prevent bugs by being more
>>> restrictive as to what enters the kernel. However, you're basing a
>>> huge trust on a large codebase. Any bug in a compiler, loader, linker
>>> or analysis tool will eventually lead to a very nasty failure in ring
>>> 0.
>>
>> True but monolithic kernels live with these things + a very large
>> untrusted/unverified kernel .
>
>I do not think that this is a good argument. Linux is reliable but at
>what price (counted in human centuries). How many projects will have the
>luck of attracting as many "eyeballs"? Also, Windows is more or less
>reliable (I believe) but at what price? How many projects can afford to
>pay that price?
Note Singularity will and is intended to be much better than Windows /Linux
. Singularity ( and Minix) both benefit from being easy to change. Windows
and Linux are static because it is so hard and risky to change.
Even your argument they have 100,000 lines vs 5-10,000,000 which is a
massive improvement. Still Minux is much bigger than 5000 if you include
all things that have access to OS data hence there is some difference in
what is a TCB.
>
>Whenever when you are considering whether or not you are going to trust
>ultimately to someone, it is wise to verify its reputation. Reputation
>of authors of Linux and reputation of authors of Windows is quite
>different.
But they don't trust anyone except themselves. The compiler will be in the
OS ( apps will be managed and hence need to be compiled by the OS at
install) and the device drivers managed who do all the access via the HAL (
including IO ports). Minux trust device driver writers to do DMA and IO.
>
>I do not aggree with Jens that language-based approach is hopeless but
>in the context of Singuarlity, this discussion is irrelevant. It might
>be interesting in case if:
>- a given system has small TCB
I think it has a small TCB . 100,000 lines of C# is not that much
considering it covers everything that has access to OS data. However a real
OS in the style of Singularity would prob be 200K or so. Still C++ is at
least twice as compact that C# in terms of lines.
>- a given system has simple and powerful security model
It has a very powerful OS /software based security model .
>- a given system follows principle of the least authority (POLA)
> (which should not be confused with POLP---permission/privilege
> and authority are two separate concepts)
I don't know the detail here but they have a lot in this area. Device
drivers do not have direct hardware access, And the run manifest states
exactly what authority the app needs and the OS can deny it. This is not
really part of the Kernel though by limiting what can access the kernels
data which they do they certainly limit the authority.
"For all resource statements in the application manifest, we assume the
existence of a security policy language that can be used to specify policies
such as trust relationships for each resource in the manifest. The exact
form of this policy language remains to be decided by the security team."}
>- a given system has proper structure
> (minimized dependency relationship)
It is probably weakest here in theory though minimizing dependencies is
standard OO practice and since nearly all of the code is reasonable C# it
does make a good attempt.
>I do not think that Singularity has any of these.
Id still argue as a Research OS it has a lot of ideas that deserve our
attention. The authors deliberately avoided many things and optimizations a
real OS have due to being out of scope.
Regards,
Ben
Sys Admin
type system and that it allows the model.
Regards,
Ben
Sys Admin
Speaking of trust they also prevent ANY form of Dynamic code loading by
processes ( code in process is fixed at startup according to the manifest) .
This is interesting as a large amount of problems come from addons etc. You
may take the attitude it's in process and cant damage the OS but the end
result is unresponsive UI or region , potential CPU loops , or more likely a
crash of the host app and hence affects the OS in the practice eg browser
crashes are annoying.
Now if you isolate every addon in its own process and address space having
10 addons will give unacceptable performance. However by running it in a
shared address space ( and memory isolation as discussed) and the same PL
ring communication then the performance of them will be the similar to in
process , yet a failed addon can be terminated without affecting the base
process. Sure this makes it harder to write addons but it will make the
apps more reliable.
Regards,
Ben
>-----Original Message-----
>From: min...@googlegroups.com [mailto:min...@googlegroups.com] On Behalf
>Of Matej Kosik
>Sent: 28 April 2009 03:41 PM
>To: min...@googlegroups.com
>Subject: [minix3] Re: Singularity ideas
>
>
Matej Kosik
Concerning Linux, do you think it is fair to count also subsystems that
are never actually used? If we count only those subsystems that are
used, how big is the kernel then in terms of lines of code?
Do you find their proposals (how to enforce security policies) attractive?
Brad White
and my views have little to do with Microsoft's business practices or anything
else. My dislike for Microsoft products comes in when I realize that no matter
what I do, the system will be controlled by someone besides myself, it will
more than likely not actually be mine (in that I only get a license to use it
and never to own it), and I know that it will most likely ship with outlook
and other programs that have proven security vulnerabilities. Their systems
are never modular (no matter how much their kernels may become). For example,
I cannot remove most of the Microsoft programs that ship with their products.
I like having control over my machine. I put quite a bit of important,
personal, and priceless information on it, and I do not want that compromised.
As of now, I still do not trust Microsoft to deliver a quality product that I
enjoy (Office is a quality product but I cannot stand its latest incarnation,
Windows Vista is a quality product, but once again the few things I enjoyed
about XP were destroyed, and now I bawk at the thought of using the darned
thing).
Sys Admin
the data below it is probably a bit less but you should count a significant
% of drivers. 60% of OS crashes are due to bad drivers ( for Windows anyway)
3301081 drivers ansic=3296641,yacc=1680,asm=1136,perl=829,lex=778,
sh=17
1258638 arch ansic=1047549,asm=209655,sh=617,yacc=307,lex=300,
awk=96,python=45,pascal=41,perl=28
544871 fs ansic=544871
376716 net ansic=376716
356180 sound ansic=355997,asm=183
320078 include ansic=318367,cpp=1511,asm=125,pascal=75
74503 kernel ansic=74198,perl=305
36312 mm ansic=36312
32729 crypto ansic=32729
25303 security ansic=25303
24111 scripts ansic=14424,perl=4653,cpp=1791,sh=1155,yacc=967,
lex=742,python=379
17065 lib ansic=17065
10723 block ansic=10723
Still id argue that with current C# or Java code it takes about 3 lines to
do what a Linux style line of C does (excluding using a Framework which you
cant in a kernel and taking into account attributes) . Id also argue that
C#/Java would have significantly less bugs per line of code than asm/c/C++
and would not be surprised to see something around 3 to 5* as many lines per
bug. It all comes down to lines of code being a pretty bad measure when
comparing to C#/Java . Even comparing C to C++ is problematic.
http://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaperOnJavaEfficiency
Shows 3 * the number of bugs in C++ compared to Java ( note only about 25%
more defects though) ,it would be even higher compared to C.
Take 100,000 lines of C# and it would prob be about 20-40K lines of C++
and 10-25K of C.
Personally id rather see 100K of nice OO code than 20K of compact C.
not that different than what has to be done with managed code permissions
and trusts (Full , partial etc) , active Directory , Managed config file
manifest , and windows policy now . Though aggregating everything in one
place ( a good thing) . Though note with security the devil is always in the
detail , look at vista UAC.
I read the paper "Access Control in a World of Software Diversity " and it
seems a good proposal though nothing on enforcing it.
Note:
"
It is at this time unclear how best to implement the enforcement of policy
in all cases. There will certainly be a discretionary access control system
governing most runtime resources. The system configuration will certainly
embody much of the installation-time policy mentioned below, and perhaps
other mechanisms will also exist. The correct blend of mechanisms for the
initial version of Singularity is not yet well understood."
Regards,
Ben
>
>
Matej Kosik
> I don't know much about Singularity security. From what i can see they are
> not that different than what has to be done with managed code permissions
> and trusts (Full , partial etc) , active Directory , Managed config file
> manifest , and windows policy now . Though aggregating everything in one
> place ( a good thing) . Though note with security the devil is always in the
> detail , look at vista UAC.
>
> I read the paper "Access Control in a World of Software Diversity " and it
> seems a good proposal though nothing on enforcing it.
I do not like the proposed solution but I like the problem they
(at last :) ) identified.
Sys Admin
this was a 2005 paper. Still it is a problem in windows Excluding
authentication you have many including.
Web site security pages
Policies (User, Group , Machine)
File Access
Active Directory integration for cross machine
netsh url access privilege
Firewall rights.
Managed privileges ( Partial Trust etc)
I think describing everything as a resource is a good and obvious idea
though (including ports) , but again its a difficult problem.
Regards,
Ben
>-----Original Message-----
>From: min...@googlegroups.com [mailto:min...@googlegroups.com] On Behalf
>Of Matej Kosik
>Sent: 29 April 2009 03:04 PM
>To: min...@googlegroups.com
>Subject: [minix3] Re: Singularity ideas
>
>
Sys Admin
written as managed applications ( Java /C#/VB.NET/Perl/Ruby/Html/Java script
etc) and hence hosted by a runtime ( you can also include browsers and web
servers in this) . Also increasingly applications are talking to other
applications ( Web services ( SOAP and REST) , cloud computing etc) .
How does Minux and micro kernels in general plan to support this now and in
future ?
Option 1)
Each run time runs in its own process along with all child processes. This
is bad as 1 app can bring the whole runtime down , completely defeating the
point of reliable OS . Sure the OS is robust but people won't view it as
such when half the apps stop working. Consider having 30 pages open in a
browser and it coming down - its quite annoying to the extent that some
browsers even restart your pages now ( pitty about the form you were just
filling out) .
Option 2)
Each child process runs in its own process and the runtime is shared code. A
crash of a app should not affect the other apps , While this works ok in
Monolithic kernels with a micro kernel the switching overhead becomes very
heavy. Take the case of a large number of load balanced SOA services that
need to frequently communicate.
Eg take a common case of an incoming request and then the service talks to
another service for a single call ( say to log something) .
Incomming Request -> network Stack -> Soap stack -> Service Hosting ->
Service 1 -> Soap stack ->Tcp/ip stack ->Network stack or shared memory ->
Tcp/ip stack -> Soap stack - Service 2 -> Call Db process -> Db talks to
file system -> fs talks to Disk driver ->
And now the ack is returned.
I would imagine that while web sites serving html could run ok (but not
great) in this mode , actual web applications would get bad performance. Its
worth noting SOA applications particularly are sensitive to the latency here
as they may pass through a number of services.
Option 3)
Is as Option2 but the shared runtime code can only be readonly pages. This
is the same as 2 just a bit safer .
Regards,
Ben
Matej Kosik
> If you mean there pseudo language and all that , i don't like it either note
> this was a 2005 paper. Still it is a problem in windows Excluding
> authentication you have many including.
>
> Web site security pages
> Policies (User, Group , Machine)
> File Access
> Active Directory integration for cross machine
> netsh url access privilege
> Firewall rights.
> Managed privileges ( Partial Trust etc)
>
> I think describing everything as a resource is a good and obvious idea
> though (including ports) , but again its a difficult problem.
I disagree. It is artificially (not inherently) complicated problem.
Consider a following scenario.
- you have a (Singularity) subsystem that you want to run
- it requires some authority to be able to provide required services
If you make sure that:
(1) a given subsystem is started in an (unbreakable) sandbox
(2) the language does not support forging arbitrary references
then the whole security problem (how to follow the principle of the
least authority---POLA) reduces to passing a given subsystem right set
of references to object it needs to talk to.
The caveat is that (1) and (2) are hard to do for Java/C#. But language
designed progressed from the time in which Java was designed and there
are languages where (1) and (2) is trivial to ensure.
There are many advantages of this scheme.
- you can forget about authentification
(what is the identity of kernel components anyway)
Authentification subsystem can be dropped from TCB.
- you can forget about reference monitor
(there are many different kinds of objects and usually
this means that you need separate reference monitor for each
and every type of object)
All the reference monitors can be dropped from TCB.
- You do not have to choose between
- security
- usability
as it is always an inherent problem of any ACL scheme.
- Basically, the effort needed to determine the authority
of a chosen component is proportional
- not to the size of the sandboxed component
- but to the size of the the trusted component that sends
it right set of references.
- The security model is simpler. What you have a references. Those
you have anyway so the situation does not get more complicated.
You do not have to deal with ridiculous security mechanisms.
Are there any other disadvantages of this scheme?
(provided that we choose a language where conditions (1) and (2) can be
trivially ensured)
Sys Admin
no dynamic code and no write access or close enough to be ok eg excluding
compiler bugs in the runtime etc )
Not sure about (2) Considering an OS like Singularity already specifies the
language( and extends it ) it should be possible. Kind of plays havock with
OO design though wouldn't it ? How do you forge a reference anyway ? If the
intermediate language is changed the signing will fail . Once loaded
Singularity compiles it ( and checks potential references ) and allows no
changes to the codebase once running. I don't think its worth implementing
security policy just to catch compiler/OS bugs.
Again i haven't really looked at security but i would have thought not
allowing ANY dynamic code , a manifest of what is required and signed
assemblies by an authority would provide very strong protection . The only
issue is certain subsystems would need trust upgraded manually when changed
( due to the signing being different) - im assuming the subsystem still has
some sort of trust/authority level which has to be manually set eg a
display driver is trusted by default to access certain IO ports to do with
display ( this is no different to the Full and Partial trust .NET uses now)
. ie if you upgrade the display driver you would have to give this authority
to the new driver. If you don't have this than a downloaded malicious app
can kill the system .
>
>There are many advantages of this scheme.
>- you can forget about authentification
> (what is the identity of kernel components anyway)
> Authentification subsystem can be dropped from TCB.
>- you can forget about reference monitor
> (there are many different kinds of objects and usually
> this means that you need separate reference monitor for each
> and every type of object)
> All the reference monitors can be dropped from TCB.
well. And i must admit they are so close to not needing it.
>- You do not have to choose between
> - security
> - usability
> as it is always an inherent problem of any ACL scheme.
>- Basically, the effort needed to determine the authority
> of a chosen component is proportional
> - not to the size of the sandboxed component
> - but to the size of the the trusted component that sends
> it right set of references.
>- The security model is simpler. What you have a references. Those
> you have anyway so the situation does not get more complicated.
> You do not have to deal with ridiculous security mechanisms.
>
>Are there any other disadvantages of this scheme?
>(provided that we choose a language where conditions (1) and (2) can be
>trivially ensured)
certainly merits attention , i mean why go to the point of having immutable
code , no pointers , managed memory , signed assembly with manifest and not
go the little step more. The only argument i can think of is they want a
layered system to catch multiple things and central administration ( eg do
you trust a Directory subsystem on a different machine , Singularity is not
distributed but you can see a lot of thinking regarding distributed like
behaviour ) but your idea certainly has merit , keep it simple and you have
less security bugs . You would still need some sort of configurable trust to
protect key components ( like port 80) and it can act as an extra layer
against allowed malicious code. After thinking about your comments an
extension of the .NET Trust system ( Full / Partial etc ) is probably better
than complex ACL's .Good Theory and KISS is nearly always better than
Perfect Theory and complexity ( due to bugs).
Regards,
Ben
>
>
Antoine Leca
> <snip>
>> But it still is a LOT of work (that should be done entirely on every
>> build you want to verify.)
>>
>> Furthermore, Minix 3
>
> Anything with access to Kernel structures is part of the TCB in
> Singularity.
Can you please explain to me why you posted all these explanations about
Singularity in response to my post, which was targeting Minix3?
Antoine
Sys Admin
I created this thread to discuss Singlarity ideas and how they apply to
Minix (and hence whether they are worth implementing in a micro kernel OS ).
The conversation just before you entered was on comparing the TCB of Minux
to Singularity.
>>> Any bug in a compiler, loader, linker or analysis tool will
>>> eventually lead to a very nasty failure in ring 0.
>> Like in Minix. Minix kernel is also compiled by an unverified compiler.
>> Just like Singularity.
>
> True, but verifying the resulting assembly code of 5000 lines is a lot
> easier than verifying the result of 100000.
8,000? without forgetting the kernel libraries ;-)), it will still hold.
your comment was relevant to the whole conversation about the size of the
TCB. Eg When comparing TCBs what is the Minux TCB which you elaborated on
and what is the Minux TCB.
Now if you change the subject to Minux TCB ,was Singularity ideas i
certainly wouldnt have but teh subject was Singularity ideas so i think i
deserve the right to tie it back to the original topic instead of meandering
especially when it was relevant :-) Am i wrong here ? If so i apologize.
Regards,
Ben
>-----Original Message-----
>From: min...@googlegroups.com [mailto:min...@googlegroups.com] On Behalf
>Of Antoine Leca
>Sent: 30 April 2009 12:08 AM
>To: min...@googlegroups.com
>Subject: [minix3] Re: Singularity ideas
>
>
Matej Kosik
discussion before we can understand each other.
Antoine Leca
Sys Admin (= bklooste = Ben) wrote :
> I created this thread to discuss Singlarity ideas and how they apply to
> Minix (and hence whether they are worth implementing in a micro kernel OS ).
> The conversation just before you entered was on comparing the TCB of Minux
> to Singularity.
Do you mean this thread should refrain from discussing Minix, just
sticking on Singularity?
If yes, it probably would have been easier to mention it, rather than
requiring me to figure out the details of your post and the relationship
with mine.
Antoine
Sys Admin
>Do you mean this thread should refrain from discussing Minix, just
>sticking on Singularity?
>
>If yes, it probably would have been easier to mention it, rather than
>requiring me to figure out the details of your post and the relationship
>with mine.
>
No one is saying it should be only Singularity.
"I created this thread to discuss Singularity ideas and how they apply to
Minix (and hence whether they are worth implementing in a micro kernel
>OS )." Which obviously != " Do you mean this thread should refrain from
discussing Minix, just
>sticking on Singularity?" in the English language at least
It may mean the thread, as should be obvious from the subject should refrain
from discussing ONLY Minix but I don't have an issue with a thread wondering
a bit though i do think it is reasonable for me to tie relevant comments
back to the subject.
However YOU were the one that raised the issue of why I tied it back to the
original topic , at the time of posting i didn't realize you intended to
fork the discussion without changing the obvious subject which is either
lazy or bad etiquette. I can understand you just read the last post and
wanted a reply to your specific email , however it sounds like you did not
bother reading the rest of the tread. Personally i think your request for an
explanation to an on topic reply on a thread i started and the incorrect but
sarcastic tone in reply to my conciliatory last message are insulting if not
downright rude.
Regards,
Ben
Alexander Ray
I've been trying to follow this with a bit of reading, and I'm really
interested in what MSR is doing with Singularity, Sing#, Spec# and
Code Contracts. I think I see how each could contribute to shortening
development and making it harder to write buggy software to begin
with.
My question is on the Code Contracts specifically. I'm a fan of
Eiffel-style Debug:Asserts in the debugging process, but for a
language that doesn't have them built-in, I've always just put them in
preprocessor directives that would print out debug messages to the
screen. I think on of the most useful things about Code Contracts is
that they're checked at compile time, so you can get rid of a lot of
edge cases before you even start running unit tests.
Is there any kind of utility/tool for this sort of thing in MINIX (in
C and/or assembly)? If not, is there an existing tool (maybe on the
GNU Toolchain) that does this that could be ported?
Thanks
~Alex