HURD

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

libOS vs FPGAs

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

User Space

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: L4-hurd Digest, Vol 46, Issue 1

> Hello,

hello 

> I am currently making researches about OS for my personal interest.

well, that is exactly like me

> After many thougths, I ask myself how it is possible to build the HURD
> quickly and to attract the maximum of people around this project.

i am also thinking about this but i lack experience.

> I think I have found a guideline. The start point of my thougth was this
> flame publication :
>
> www.cl.cam.ac.uk/research/srg/netos/papers/2005-hot-os-vmm.pdf

baby, this link does *not* exist.

> www-128.ibm.com/developerworks/library/l-linuxvirt/index.html

well i will read them when my ISP will want. my broadband broke down,
dont know how long will it take to fix 

> programatica.cs.pdx.edu/House/

well, i read that 1.5 months ago and was much interested in it.

> We will rewrite all the microkernel in Haskell.

have you checked "Mercury Project"?

> I look forward to your answer,

wait untill my ISP waves a green-flag

> Happy New year :)

Oh! thanks & same to you.

--  arnuld
http://arnuld.blogspot.com/

Re: L4-hurd Digest, Vol 46, Issue 1

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

P2P

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: HURD

Hello "John",

let me first say hello, and that you are welcome to share your ideas
with us, but that there are a couple of things you can do to entice
more useful replies.

First, have you browsed through the mailing list archive?  There are
many interesting discussions in there, which should give you an idea
about some of the design decisions we have tentatively made.  Many
things have changed over the years, but I think that there is a
reasonably clear picture what our primary focus of work is.

If you do this, you may find out that our primary interest is not the
underlying hardware.  We want to write a general purpose operating
system, which means that we target the hardware that's available to
most people first, and try to be portable.  Relying on specific
devices, even interesting ones such as FPGA, is not on the agenda, and
there seem to be no compelling reasons to do so.

Although interesting to see what resources you have found recently, we
can make more use of your input if you try to put it into the context
of the Hurd project.  You don't need to write essays, but a couple of
sentences why something seems relevant to this project would be very
much appreciated.  I am less interested in why you think the work is
interesting to you, but why you think that the work should be
interesting for us, given the work we have already done.

Your three phases plan did not give me any idea how you think the
user-space of the system should look like.  Maybe you can formulate
some goals for the end-user that the system should meet, so that we
can work backwards from there and fill in the gaps.

My last note is personal.  You decided to post anonymously.  This
means that we have no idea who you are.  You can build a reputation
under any pseudonym, but you should be aware that all contributions to
the Hurd must have their copyright assigned to the Free Software
Foundation, and if you reach that point you will have to reveal your
identity to the FSF at the very least.  My personal preference is to
talk and invest time into relationships with people who can become my
friends, and I have made many friendships working on the Hurd project.
By remaining anonymous, you are depriving yourself and us of that
opportunity.

Thanks,
Marcus

Position paper

Marcus and I have written a short position paper [1] which we have
submitted to HotOS XI [2].

The goal of the paper is to articulate the problems we are trying to
solve (security, resource management and integration) and to outline a
framework for their solution.

The system we propose is capability based.  Such systems, it has been
shown, can be used to straightforwardly realize dynamic POLA and, when
designed carefully, can be made relatively extensible.  The fine
granularity attainable with capabilities is also desirable for
resource management.

To fix the resource management problems, we introduce an abstraction,
resource pools, which is similar to EROS's space banks or resource
containers.  Resource pools account resources and encapsulate a
resource scheduling policy.  Resource pools form a policy hierarchy
allowing tighter constraints to be placed on derived pools.  This
allows applications to decompose access to resources and refine policy
without having to resort to full-scale interposition.  In this way,
policy can be set according to the process hierarchy but realized by
the resource manager.  A practical implication is that the central
server can only implement a static number of policies reducing
generality.  We argue that, in practice, only a small number of
policies are actually required.  Finally, we introduce mechanisms to
allow applications to control multiplexing giving applications, in
particular, more control over the eviction policy.

Although the paper has already been submitted, we are still interested
in comments on how to improve it for the final version (if it is
accepted).  We are also very interested in discussing reactions to
this proposal.

Thanks,
Neal

[1] http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf
[2] http://www.usenix.org/events/hotos07/cfp/

Potential use case for opaque space bank: domain factored network stack

I just read the "Network Subsystems Reloaded" paper by Sinha, Sarat and
Shapiro. Part of it discusses a network stack implemented for EROS with
several isolated processes. As such layout typically lacks performance,
they at least avoid copying accross protection boundaries with shared
memory.

A client of the TCP stack would give it access to four memory regions:
two for TCP headers and two for payloads, for transmission and
reception. This avoids DOS attacks by clients because the stack doesn't
use it's own limited memory to work on behalf of it's clients.

But to ensure correctness of network packets, header sections must not
be writable by the client.

With the design of space banks as it was vigourously debated earlier,
would that be even possible? IIRC, it was not considered desirable that
a process A could give authority to some of it's resources (here,
memory) to another process B while losing some of it's own authority to
it (but having the ability to reclaim it back).

Curiously,
Nowhere man
--

-- 
nowhere.man <at> levallois.eu.org
OpenPGP 0xD9D50D8A

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: Potential use case for opaque space bank: domain factored network stack

Hi Pierre,

At Fri, 5 Jan 2007 21:59:51 +0100,
Pierre THIERRY <nowhere.man <at> levallois.eu.org> wrote:
> I just read the "Network Subsystems Reloaded" paper by Sinha, Sarat and
> Shapiro. Part of it discusses a network stack implemented for EROS with
> several isolated processes. As such layout typically lacks performance,
> they at least avoid copying accross protection boundaries with shared
> memory.
> 
> A client of the TCP stack would give it access to four memory regions:
> two for TCP headers and two for payloads, for transmission and
> reception. This avoids DOS attacks by clients because the stack doesn't
> use it's own limited memory to work on behalf of it's clients.
> 
> But to ensure correctness of network packets, header sections must not
> be writable by the client.
> 
> With the design of space banks as it was vigourously debated earlier,
> would that be even possible? IIRC, it was not considered desirable that
> a process A could give authority to some of it's resources (here,
> memory) to another process B while losing some of it's own authority to
> it (but having the ability to reclaim it back).

Right, thanks for bringing this up.  This has been discussed before,
please have a look at the following e-mails.  The example there was
the "ping" example (whatever that is, I can't find the original mail
where it came up), but I understand that it has essentially the same
properties as the TCP stack you describe above.

Bas' mail: http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00524.html
My response: http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00526.html

I will repeat my response in short here to be clear.  I admit that
this is a good and useful example for such an operation.  Another
example I consider to be similar is the L4.sec kernel memory managed
in user space.  Note that the network driver wants to do DMA
and thus needs to be able to lock down the memory anyway, at least for
a short period of time.  So, in a sense the TCP stack already
dominates the user, it is part of the TCB.  In this case, the
implementation details of how the memory allocation is organized is of
minor relevance to this question, IMO.

The core point here is that process A does not give any authority to
process B that it didn't already have or could have (in principle).

Bas suggested that similar scenarios could pop up outside of the TCB.
This could happen when DMA transfers can be secure and a number of
other assumptions are made.  I am not really convinced at this point
that such scenarios as Bas' non-cooperatively shared USB high-speed
network adapter are all that practical, common or relevant.

Thanks,
Marcus