headers
Jeremy Shaw | 2 Oct 17:33
Gravatar

Barrelfish: microkernel(?) + capabilities + distributed heterogeneous cores + formal proofs + Haskell

Since no one else has mentioned it yet, let me present, The Barrelfish  
Operating System:

http://barrelfish.org/

As described in this paper:

http://barrelfish.org/barrelfish_sosp09.pdf

    "We investigate a new OS structure, the multikernel, that treats  
the machine as a
network of independent cores, assumes no inter-core sharing at the
lowest level, and moves traditional OS functionality to a distributed
system of processes that communicate via message-passing."

This paper describes the use of DSLs and DSL -> C compilers written in  
Haskell to generate low-level kernel code:

http://www.barrelfish.org/fof_plos09.pdf

The aim is to be able to build provably correct DSLs and compilers  
fast enough that you would actually prefer to use them as part of the  
development process instead of just doing the low-level C code by hand.

- jeremy
Permalink | Reply | 0 comments |
headers
Jonathan S. Shapiro | 4 Oct 20:13

Re: Broken dream of mine :(

On Tue, Sep 29, 2009 at 9:49 PM, arnuld uttre <arnuld.mizong <at> gmail.com> wrote:
>
> Now I wonder why Viengoos was created as an alternative if Coyotos was fine.

This is a question that Neal should answer for himself, but I think it
is fair to say that Neal wanted to explore the cost/benefit of
cooperative resource management, and he believed that Coyotos was not
designed to do this. I believe that the experiment could have been
done on Coyotos, but sometimes buildling fresh is a better way to
understand issues.

Cooperative resource management is a promising idea, and it is
particularly important as the world moves toward heavier use of safe
languages. Unfortunately, it conflicts directly with notions of
program isolation, and therefore with security and robustness. The
conflicts can be managed, but they *need* to be managed. So far, very
little work has looked at managing those conflicts.

Coyotos moves very strongly in the opposite direction. We favor
isolation over everything else. This decision was based on empirical
evidence of real [mis]behavior in real systems in real production
scenarios. But with safe languages gaining acceptance, I think we now
would need to re-examine that.

I think that cooperative resource management needs to be explored, and
Viengoos is one of several systems that is doing that. I would
hesitate very strongly at this point to build a production system on
top of a kernel/system designed to explore cooperative resource
managment. The security implications are serious, and not yet
adequately understood.
(Continue reading)

Permalink | Reply | 8 comments |
headers
William Leslie | 5 Oct 09:12
Picon
Gravatar

Re: Broken dream of mine :(

2009/10/5 Jonathan S. Shapiro <shap <at> eros-os.com>:
> Coyotos moves very strongly in the opposite direction. We favor
> isolation over everything else. This decision was based on empirical
> evidence of real [mis]behavior in real systems in real production
> scenarios. But with safe languages gaining acceptance, I think we now
> would need to re-examine that.

I am very glad you have bought this out.  I have a few thoughts on the
subject, which I thought I would share.  None may be new to the
majority here (certainly not to you, shap, considering your current
position), but I thought they were worth collecting together in one
place.  I know my English is dry so I won't be offended if I come
across anyone that tl;dr.

0. Language level object models tend to be finer grained than those
exposed by the operating system.

This item is to be taken with a grain of salt, because unix is best
used when composing simpler processes at a fine granularity. However,
this does not seem to be the common pattern today, and I think there
are two different reasons.  Antrik has mentioned before that the
concept of the monolithic application is designed to serve the
interests of the proprietary software developer - so the user can
associate features (that could have been obvious for the user to
implement had the program been structured better) with the
application; I think that the resulting impression on modern
programmers is sadly not going away in the short term.

There is another reason, which is that the environments provided by
some languages simply feel much nicer than that which unix provides.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Michal Suchanek | 5 Oct 10:57
Picon
Favicon
Gravatar

Re: Broken dream of mine :(

Hello

2009/10/5 William Leslie <william.leslie.ttg <at> gmail.com>:

>
> There is another reason, which is that the environments provided by
> some languages simply feel much nicer than that which unix provides.
> The filesystem, for example, feels like a duplicate object model, with
> less transparent support from the (most?) language.  Given the
> distance some languages allow you to get from the operating system,
> moving from the status quo to fine-grained objects the user can
> interact with seems possible only when arbitrary, self-describing data
> structures and functions become the axioms out of which the system is
> composed.  The Hurd has bought us a long way here : it looks like it
> would not take much to publish functions and objects for use from
> other programs with pyhurd; going from there to transparent sharing of
> functions and data does not seem like much of a stretch, but this
> would be more obvious in a system engineered around language / vm
> level sharing, rather than process / application level.
>
> The impression I am trying to give here is that the sort of
> interactivity that Antrik talks about in his post[1] on Deep Mehta may
> be much more applicable when there is less distance between objects
> and functions as the system sees them and objects as the application
> developer sees them.
>

The Deep Mehta project is very interesting, thanks for sharing the link.

It also makes my earlier point clear: POSIX is ancient technology.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan S. Shapiro | 5 Oct 15:50

Re: Broken dream of mine :(

On Mon, Oct 5, 2009 at 12:12 AM, William Leslie
<william.leslie.ttg <at> gmail.com> wrote:
> 2009/10/5 Jonathan S. Shapiro <shap <at> eros-os.com>:
>> But with safe languages gaining acceptance, I think we now
>> would need to re-examine that.
>
> 0. Language level object models tend to be finer grained than those
> exposed by the operating system.

Yes. This can be a blessing or a curse. Finer grain lets you pack
concepts more tightly, but there is such a thing as an object that is
too small to adequately do the job. We don't teach OO programming very
well in school, so this tends to be a problem in real programmers.

Another way to say this is that factoring is only good when the
concepts involved actually factor. When they don't, you just end up
making things more complicated.

> The filesystem, for example, feels like a duplicate object model, with
> less transparent support from the (most?) language.

Perhaps. But recall that it is almost impossible to do a generic
security model for a general object system. The fact that the file
system interface in POSIX (and most other systems) is designed around
streams and directories is core to the R/W/RW security model. The
problem is that we need to know the *semantics* of the operation
before we can do a security design. If the operation set is subject to
change/extension, we lose that.

Note that this makes out-of-TCB file systems a huge issue.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alan Grimes | 5 Oct 17:58
Favicon

Re: Broken dream of mine :(

> It looks like a pure capability system without a POSIX blanket over it
> would be a better match for the Deep Mehta desktop than the Hurd/mach
> which forces POSIX to all user accessible interface where forcing it
> is possible.

I am still deeply sceptical of capabilities, however I must
wholeheartedly endorse your position on POSIX. That is exactly why Minix
sucks. =(

--

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.
Permalink | Reply | 0 comments |
headers
William Leslie | 6 Oct 05:14
Picon
Gravatar

Re: Broken dream of mine :(

2009/10/6 Jonathan S. Shapiro <shap <at> eros-os.com>:
> On Mon, Oct 5, 2009 at 12:12 AM, William Leslie
> <william.leslie.ttg <at> gmail.com> wrote:
>> 2009/10/5 Jonathan S. Shapiro <shap <at> eros-os.com>:
>>> But with safe languages gaining acceptance, I think we now
>>> would need to re-examine that.
>>
>> 0. Language level object models tend to be finer grained than those
>> exposed by the operating system.
>
> Yes. This can be a blessing or a curse. Finer grain lets you pack
> concepts more tightly, but there is such a thing as an object that is
> too small to adequately do the job. We don't teach OO programming very
> well in school, so this tends to be a problem in real programmers.
>
> Another way to say this is that factoring is only good when the
> concepts involved actually factor. When they don't, you just end up
> making things more complicated.

This is an interesting problem, and one that doesn't have a
straightforward answer in most of the languages today.  A similar
problem is how to determine who pays for what resources at this level.
 I think I have a vague idea on a solution, which I might save for a
future blog entry (there are a couple of prerequisites to this
discussion).

>> 1. Safe languages introduce new opportunities for optimisation.
>
> Not in practice. Current safe languages turn out to have a bunch of
> fairly low-level design issues that make optimization quite difficult.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan S. Shapiro | 7 Oct 22:12

Re: Broken dream of mine :(

On Mon, Oct 5, 2009 at 8:14 PM, William Leslie
<william.leslie.ttg <at> gmail.com> wrote:
>
> 2009/10/6 Jonathan S. Shapiro <shap <at> eros-os.com>:
> > Trivial example 1: The "readonly" keyword in C# is (correctly and
> > necessarily) ignored by most C# compilers. Exercise for the reader:
> > explain why.
> Any discussion of optimisation needs to keep in mind the premise that
> optimisations are only applicable if they preserve the semantics of
> the language.  Any attempt to take advantage of readonly would need to
> show that, on the domain of interest, no paths modify the region of
> interest, and that there are no memory barriers; effect analysis of
> this depth is very expensive if all you are getting out of it is to
> show that a readonly is a loop invariant...

Ahh. You are forgetting that both the Java and the C# runtime
environments have preemptive concurrency. In many interesting cases,
the analysis you want simply cannot be done unless you prohibit
runtime class loading.

> , indeed, if you are doing
> that kind of analysis, readonly is redundant.

You misunderstand what readonly does. It allows you to state, for
example, that a class member field is unchanging. In that situation,
it is not at all redundant.

> > Yes. They eliminate between 50% and 60% of current vulnerabilities.
> >
> > But be careful. You need to test and calibrate the runtime cost of this...
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Leslie | 11 Oct 09:17
Picon
Gravatar

Re: Broken dream of mine :(

2009/10/8 Jonathan S. Shapiro <shap <at> eros-os.com>:
> On Mon, Oct 5, 2009 at 8:14 PM, William Leslie
> <william.leslie.ttg <at> gmail.com> wrote:
>>
>> 2009/10/6 Jonathan S. Shapiro <shap <at> eros-os.com>:
>> > Trivial example 1: The "readonly" keyword in C# is (correctly and
>> > necessarily) ignored by most C# compilers. Exercise for the reader:
>> > explain why.
>> Any discussion of optimisation needs to keep in mind the premise that
>> optimisations are only applicable if they preserve the semantics of
>> the language.  Any attempt to take advantage of readonly would need to
>> show that, on the domain of interest, no paths modify the region of
>> interest, and that there are no memory barriers; effect analysis of
>> this depth is very expensive if all you are getting out of it is to
>> show that a readonly is a loop invariant...
>
> Ahh. You are forgetting that both the Java and the C# runtime
> environments have preemptive concurrency.

Perhaps I understand the memory model of neither, then.  I mean to say
that effects of different threads only need to be ordered at memory
barriers, so effects on different regions can be coalesced within a
thread.  Consider the canonical example:

global_flag = True

def some_loop():
    while global_flag:
        something()
(Continue reading)

Permalink | Reply | 0 comments |
headers
olafBuddenhagen | 27 Oct 08:29
Picon

Re: C++

Hi,

On Thu, Sep 24, 2009 at 01:28:18PM -0600, Andrew Waidler wrote:

> Another point is that compilers sometimes  over-optimize to the point
> of causing security bugs, which I think this  was the recent example
> in Linux; http://lwn.net/Articles/341773/

The compiler didn't actually cause a security bug. What it did was
optimize code that was already a security bug in itself, in a way that
would be perfectly safe in a normal situation; but in combination with
one or two other kernel bugs that broke gcc's assumptions, it was
elevated from "merely" a DoS to a code injection.

This was an extremely specific situation; concluding that compilers are
generally dangerous would be ridiculous.

-antrik-
Permalink | Reply | 0 comments |

Gmane