headers
Marcus Brinkmann | 5 Sep 19:22
Picon
Favicon

Forward: some thoughts about map vs. copy vs. membranes

Hi,

just filing some random thoughts for the archive.

The discussion about mechanisms for capability delegation was framed
by contrasing L4's map model and other kernels (Mach, EROS) copy
model.  Later, on cap-talk, a third idiom came up: membranes, which
have mapping semantics plus every capability fetched through a
membraned capability is limited by the lifetime of the membrane as
well.  For example, if you look up a file object in a directory
object, with membrane semantics the file capability is revoked also
when the directory capability is revoked.

It is worth repeating the difficulty in implementing a generic
membrane: If a membraned capability is fetched through a membraned
capability, the lifetime of that capability is now generally bound by
two membranes.  Repeating such operations establishes a N-to-M
relationship between membranes and capabilities, which raises storage
allocation concerns.  Only special cases are easy to handle, for
example if the two membranes are already related (one dominating the
other).  Unfortunately, membrane semantics are often desirable.

The main point I want to get across in this mail is that the
discussion about map and copy was at best misleading.  By switching to
a different point of view, it can be shown that ***L4 X.2 implements
membrane semantics*** rather than map semantics.  So, the discussion
should not have been about map vs. copy but about membranes vs. copy.

It's easy to show that L4 X.2 implements membrane semantics: First,
the only delegatable capabilities are frame capabilities, so there is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan S. Shapiro | 5 Sep 20:48

Re: Forward: some thoughts about map vs. copy vs. membranes

On Wed, 2007-09-05 at 19:22 +0200, Marcus Brinkmann wrote:
> It is worth repeating the difficulty in implementing a generic
> membrane: If a membraned capability is fetched through a membraned
> capability, the lifetime of that capability is now generally bound by
> two membranes.

Unfortunately, it is worse than this. If a capability is returned across
a membrane boundary by an operation of the form:

	cresult = c0->method(data args, c0, c1, ..., cn)

then the lifetime of cresult is bounded by the lifetimes of c0 .. cn.
While a binary tree can express this dependency, the logical dependency
chain is not restricted to two inputs per output. The problem is that we
cannot know at the time of membrane formation which capability in {c0,
cn} will die first.

> It's easy to show that L4 X.2 implements membrane semantics...

Because membrane injection is not restricted to cases of delegation,
membranes require full interposition of all invocations in general. In
order for L4 kernel to implement membrane semantics, it would be
required to do full causal dependency tracking across IPC.

The L4 map primitive does implement a restricted sub-case of membrane
semantics, but this sub-case is not useful. The problem is that (1) a
generalized membrane can only be implemented at user level, and (2) when
a user-level implementation exists, the additional membranes inserted by
the kernel in the case of map are at best not helpful and at worst may
create challenges for selective membrane revocation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 6 Sep 05:00
Picon
Favicon

Re: Forward: some thoughts about map vs. copy vs. membranes

At Wed, 05 Sep 2007 14:48:40 -0400,
"Jonathan S. Shapiro" <shap <at> eros-os.com> wrote:
> 
> On Wed, 2007-09-05 at 19:22 +0200, Marcus Brinkmann wrote:
> > It is worth repeating the difficulty in implementing a generic
> > membrane: If a membraned capability is fetched through a membraned
> > capability, the lifetime of that capability is now generally bound by
> > two membranes.
> 
> Unfortunately, it is worse than this. If a capability is returned across
> a membrane boundary by an operation of the form:
> 
> 	cresult = c0->method(data args, c0, c1, ..., cn)
> 
> then the lifetime of cresult is bounded by the lifetimes of c0 .. cn.
> While a binary tree can express this dependency, the logical dependency
> chain is not restricted to two inputs per output. The problem is that we
> cannot know at the time of membrane formation which capability in {c0,
> cn} will die first.

I do agree that the lifetime of a membraned capability is not
necessarily bound by one or two membranes.  The number "2" above was
only an example.  It is easy to construct an arbitrary number of
dependencies by repeating the above operation, adding one more
membrane dependency at each iteration.

I think the example you are bringing up is interesting.  However, I am
not sure why you think that cresult in your example should generally
be limited by any other capability than c0.  There are peculiarly few
operations involving capabilities as arguments, and even less return
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan S. Shapiro | 6 Sep 18:33

Re: Forward: some thoughts about map vs. copy vs. membranes

On Thu, 2007-09-06 at 05:00 +0200, Marcus Brinkmann wrote:
> At Wed, 05 Sep 2007 14:48:40 -0400,
> "Jonathan S. Shapiro" <shap <at> eros-os.com> wrote:
> > 
> > 	cresult = c0->method(data args, c0, c1, ..., cn)
>
> I think the example you are bringing up is interesting.  However, I am
> not sure why you think that cresult in your example should generally
> be limited by any other capability than c0.  There are peculiarly few
> operations involving capabilities as arguments, and even less return
> capabilities, so use cases to analyze are rare....

I think this because the membrane that has been under discussion on
cap-talk is the one in which this is the defined behavior.

The problem is that the term "membrane" is being overloaded: it is both
a generic term meaning "a mechanism (in our context: a process) that
enforces transitive revocation policies by injecting wrappers and
tracking propagation'. We have also used it to refer to an particular
instantiation that implements the particular policy that I have
described above.

I suggest that in the future, to avoid ambiguity, we should call this
the Causal Dependency Membrane.

The causal dependency membrane is certainly not the only possible
membrane.

So: I should restate what I said about L4 implementing membranes:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bas Wijnen | 23 Sep 18:02
Picon
Favicon

New kernel to play with

Hello everyone,

You can consider this the end of my long break, although I'm not sure
how active I can be in the near future. :-)  But I have interesting
things to tell, so I shall not delay:

While waiting (very passively) for Coyotos to get ready, I decided that
I wanted to try writing a simple kernel myself.  It is based mostly on
the discussions I had here, most notably with Jonathan and Marcus.  It
was easier than I expected, which means it is running.  I also tried
porting glibc, but gave up on that.  Instead I wrote some minimal libc
myself (which is very non-optimized, but works mostly).  The current
state is such that it can run nethack (in text-mode).

For the impatient, here's how to see that (commands are for a Debian
system, adjust them if you have something else):

# apt-get install build-essential qemu automake1.10 autoconf git-core
# apt-get install rubber texlive-latex-base
$ git clone git://82.93.13.222/kernel
$ cd kernel
$ (mkdir nethack && cd nethack && apt-get source nethack)
$ ./autogen.sh
$ make
$ make qemu

Then when the system says "Waiting for events", type "run nethack" and
have fun. :-)

If it doesn't work, or you are more interested in the kernel than in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luca Cappelletti | 25 Sep 10:06
Picon
Gravatar

Re: L4-hurd Digest, Vol 54, Issue 3

This Rocks!!
thanks a lot!!!,

Luca

-- 
---
Luca Cappelletti
Infodomestic.com

"...Together we stand, divided we fall."

.O.
..O
OOO

GTalk: luca <dot> cappelletti <at> gmail <dot> com
Jabber: luca <dot> cappelletti <at> jabber <dot> org
MSN: luca <underscore> cappelletti <at> hotmail <dot> com
Skype: luca <dot> cappelletti
Linux Registered User: #223411
Ubuntu Registered User: #7221
http://www.advogato.org/person/mutek/
http://persone.softwarelibero.org/person/mutek
https://wiki.ubuntu.com/LucaCappelletti/
"l'intelligenza è utile per la sopravvivenza se ci permette di
estinguere una cattiva idea prima che la cattiva idea estingua noi"

"La chiave di ogni uomo è il suo pensiero. Benché egli possa apparire
saldo e autonomo, ha un criterio cui obbedisce, che è l'idea in base
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jonathan S. Shapiro | 1 Oct 23:18

Hiring again

I'm very pleased to announce that The EROS Group has recently been
awarded two new contracts, which means that we need to start hiring
again. We are looking for people with experience in kernels, virtual
machines, and/or compilers.

The positions will be in the Baltimore, MD area. Relocation is possible.
Salary will be market-competitive based on experience.

Because these positions are funded by US Government contracts, we can
only consider US citizens or permanent residents. We are also starting
the process of organizing our business and capitalization plans, and we
expect to have further positions open in the fairly near future that
will not be constrained this way, so if you aren't a US resident, don't
give up hope.

If you would like to find out more about what we are up to and what
these positions entail, please feel free to get in touch with me.

Jonathan
--

-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org
Permalink | Reply | 0 comments |

Gmane