headers
Shakthi Kannan | 4 Sep 2005 21:10
Picon
Favicon

L4-hurd on IBM T41

Greetings!

I am trying to test L4-hurd on my thinkpad T41 (x86).
I am following the documentation provided at:

http://hurd.gnufans.org/bin/view/Hurd/HurdOnL4

The following four steps under compiling Hurd-L4 are
redundant?

$ mkdir /l4hurd/boot
$ cp laden/laden /l4hurd/boot
$ cp wortel/wortel /l4hurd/boot
$ cp physmem/physmem /l4hurd/boot

... because "make install" already moves laden, wortel
and physmem to /l4hurd/boot?

My entry in /boot/grub/menu.lst for the l4-hurd entry:

title 		GNU Hurd on L4Ka Pistachio 0.4
root		(hd0,0)
kernel		/l4hurd/boot/laden -D
module		/l4hurd/boot/ia32-kernel
module		/l4hurd/libexec/l4/sigma0
module		/l4hurd/boot/wortel -D
module		/l4hurd/boot/physmem -D
module		/l4hurd/boot/physmem
module		/l4hurd/boot/physmem
module		/l4hurd/boot/physmem
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 4 Sep 2005 21:45

Sawmill's dataspaces and the Hurd's physmem

During my presentation of the design of the Hurd on L4 to the Dresden
group, Lars Reuther asked me if I had considered Sawmill's dataspace
model and if so why I had rejected it.  My answer was that we want to
be able to catch any errors at the time of data acquisition and that
relying on a file system server to provide a mapping to the data does
not guarantee this: a malicious server can unmap mappings and refuse
to remap them; or if the server is shorter lived than the client, the
the data becomes inaccessible to the client when the server exits.

Lars asked for more details.  Unfortunately, I failed to provide a
coherent and complete argument: my problem was mainly that I came to
this conclusion fairly early in the design process and had since
forgotten too many details of Sawmill's architecture to reconstruct my
argumentation.  I've recently revisited some related issues and am now
in a position to better answer Lars's question.  My primary reference
for the Sawmill framework is [1].

I think I may be able to best explain the problem with an
illustration: consider a server providing access to a file system
backed by a disk.

In the Sawmill dataspace model [1], the file system server is a
dataspace manager which likely provides a dataspace for each file.
When a task wants to use a file, it first identifies the dataspace
associated with the file (e.g. gets a capability to the file from the
DM) and attaches it to its address space (e.g. tells its pager to
associate a portion of the VM with the capability).  "After an attach,
the region mapping forwards all page fault requests in that region to
the dataspace manager.  The dataspace manager resolves the faults with
map or grant operations."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ronald Aigner | 5 Sep 2005 11:15
Picon
Favicon

Re: Sawmill's dataspaces and the Hurd's physmem

Hi,

Neal H. Walfield wrote on 09/04/2005 09:45 PM this:
<snip>
> In the Sawmill dataspace model [1], the file system server is a
> dataspace manager which likely provides a dataspace for each file.
> When a task wants to use a file, it first identifies the dataspace
> associated with the file (e.g. gets a capability to the file from the
> DM) and attaches it to its address space (e.g. tells its pager to
> associate a portion of the VM with the capability).  "After an attach,
> the region mapping forwards all page fault requests in that region to
> the dataspace manager.  The dataspace manager resolves the faults with
> map or grant operations."
>
> I understand this to mean that a client depends on a DM to:
>
>  - provide mappings to data
>  - provide resources backing the data
>
> When a client requests some data from a dataspace, the DM provides a
> mapping to the client.  The client can proceed to use the data,
> however, at any point, the server could cause the mapping to be
> unmapped and possibly render the data inaccessible.  The implication
> is that the client must either trust the server to always provide the
> mapping or be prepared to recover should the data disappear.  The
> latter approach can be simplified by making a physical copy of data
> before committing to using it (which can be done by interposing a
> second DM between the DM and the client).  General use of this tactic
> means a lot of cycles will be spent copying bytes and a reduction in
> the amount of physical memory sharing in the system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 5 Sep 2005 11:42

Re: Sawmill's dataspaces and the Hurd's physmem

> It appears to me that a file system server providing a file to a client
> always belongs to that client's trusted computing base. The FS server
> has to belong to the client's TCB, because it will provide the client
> with the content of a file. It may alter that content in any possible
> way before handing it to the client.
> 
> Given that trust relationship, the revocation of pages may or may not be
> part of the protocol the client and the server agreed upon. If no pages
> shall be revoked, the client *knows* that the server will not revoke
> pages, because the client trusts the server.
> 
> Therefore, the FS server can be the DM for the file, the client
> requested: No need to drop that approach.

Data integrity is an orthogonal issue from providing data
(i.e. transferring it) and holding data (e.g. mapping).  Data
integrity can be guaranteed using cryptographic means.  (Indeed,
confidentiality, another separate issue, can as well.)

Consider "Reducing TCB size by using untrusted components---small
kernels versus virtual-machine monitors" by Hohmuth et al: untrusted
L4Linux servers are securely used to fulfill operation dependencies.
In this model, I think having the trusted components depend on the
untrusted L4Linux servers to provide mappings of data may violate
these security requirements.

Thanks,
Neal
Permalink | Reply | 0 comments |
headers
Bas Wijnen | 5 Sep 2005 12:24
Picon
Favicon

Re: Sawmill's dataspaces and the Hurd's physmem

On Mon, Sep 05, 2005 at 11:15:46AM +0200, Ronald Aigner wrote:
<snip>
> It appears to me that a file system server providing a file to a client
> always belongs to that client's trusted computing base. The FS server
> has to belong to the client's TCB, because it will provide the client
> with the content of a file. It may alter that content in any possible
> way before handing it to the client.

There are several levels of trust.  The client must trust the filesystem to
give data it wants to handle, no matter which route it uses to actually get
the data.  Trusting the server so much that it's allowed to hang, crash, or
even take over the client is a completely different level of trust.

System servers such as physmem automatically get that trust, because there is
nothing you can do about it.  Physmem can just change your executing code if
it wants, for example.  However, for a filesystem (and especially one from an
other normal user) such trust is not a good idea.

What we call "trusting a process" in the Hurd (which is something we want to
avoid usually) is a lot more than accepting data for display to the user, for
example.  If the user wants to start executing that data, then appearantly he
trusts the source, so it should be good.  But if he doesn't, then we shouldn't
force that trust on him.

Thanks,
Bas Wijnen

--

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Pöss | 5 Sep 2005 21:59
Picon
Favicon

Re: Sawmill's dataspaces and the Hurd's physmem

Neal H. Walfield wrote:

>I understand this to mean that a client depends on a DM to:
>
> - provide mappings to data
> - provide resources backing the data
>
>*snip*
>                    [ Physmem DM ]
>                          |
>                          v
>                      [ FS DM ]
>                          |
>                          v
>                      [ client ]
>
>  
>
The design for a Dataspaces environment would be as follows:
Simplified you've got:
- Dataspace Manager providing open / close / map / grant
- Region Mapper providing attach / detach and pf handling
- client

client and region mapper are in the same address space(AS). Think
of a region a continous area of virtual memory in the clients AS
that makes a part of a dataspace available to the client.

  [ dataspace manager ]     
          |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 5 Sep 2005 22:31

Re: Sawmill's dataspaces and the Hurd's physmem

At Mon, 05 Sep 2005 21:59:30 +0200,
Bernhard Pöss wrote:
> The design for a Dataspaces environment would be as follows:
> Simplified you've got:
> - Dataspace Manager providing open / close / map / grant
> - Region Mapper providing attach / detach and pf handling
> - client
> 
> client and region mapper are in the same address space(AS). Think
> of a region a continous area of virtual memory in the clients AS
> that makes a part of a dataspace available to the client.
>                
>   [ dataspace manager ]     
>           |
>   request page for region
>           |
>   [ region mapper | client ]
>           |             |
>           |--<--- PF -<-|
>          
> 
> A page fault scenario would be as follows:
> 1. The client triggers a page fault
> 2. The region mapper (pager of client) receives PF
> 3. The region mapper requests the page from the dataspace manager 
> (possibly with a timeout)
> 4.A The dataspace manager maps/grants the page to the region mapper and 
> thus to the client (same AS)
> 4.B The dataspace manager denies to map the page / timeout fires
> 5. The region mapper is free to act upon the behaviour of the dataspace
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal H. Walfield | 6 Sep 2005 08:15

Re: Sawmill's dataspaces and the Hurd's physmem

> It appears to me that a file system server providing a file to a client
> always belongs to that client's trusted computing base. The FS server
> has to belong to the client's TCB, because it will provide the client
> with the content of a file. It may alter that content in any possible
> way before handing it to the client.

I'd like to add that we often don't even care about the correctness of
content.  Consider the web: I don't trust web servers to provide me
with correct data and I generally have no way to computationally
verify that the data is correct.  Nevertheless, I find the web useful
with the caveat that the data may be either malicious or incorrect.

Thanks,
Neal
Permalink | Reply | 0 comments |
headers
ness | 7 Sep 2005 19:04
Picon

Re: Patch for idl4

I have written a new set of patches. It basically ports task and physmem
to use idl4-generated interfaces, but there are other enhancements, too
(see logs [not in patches]). There is a little mess with my patch names,
as sometimes newer versions replace older onces and sometimes they only
enhance them. The order of applying patches is:

patch.idl4-v3 (to the idl4-1.0.2 source)
patch.hurd-l4 (from my prior post, to the plain cvs source)
patch.hurd-l4-v2
patch.ruth-example (from my prior post)
patch.ruth-example-v2
patch.task
patch.physmem

The files ruth/task-user.c, deva/task-user.c and
libhurd-mm/physmem-user.c can be deleted

summary of enhancements:
-generated interfaces (*_client.h) are linked to include/hurd/interfaces
-if the source file (*.idl) isn't listed in the nonpublic_interfaces
   variable
-physmem exports and is (mostly) called through generated interfaces
-task exports and is called through generated interfaces
-ruth has an up-to-date interface, but doesn't export it

about the map stub exported by physmem:
As the map stub actually has a variable number of parameters, it can't 
be described properly using CORBA. This implicitly means, the idl4 
generated interface will never be correct. That shows why I always 
encourage people to wrap generated stubs into other headers. This allows
(Continue reading)

Permalink | Reply | 0 comments |
headers
ness | 13 Sep 2005 13:42
Picon

Re: Patch for idl4

Hi there, here are some new patches. Actually they aren't that useful
but I had some free time and it didn't take that long. Basically, I
merged racin's cap patch and my idl4 patches. (I know the cap patch
isn't complete yet). The patch.orig is the actual patch posted by racin,
but it doesn't patch configure.ac and Makfile.am, as there were some
colissions. The patch.idl4 solves this issue. It actually does some
other things, it gives the cap server an interface that looks like the
idl4 generated ones and does some changes in libhurd-cap (I know it's
obsolete [maybye remove it?], the only thing I did was changing the name
of the exported header to lib-cap.h and make it compile again). The
patch-v2 is a little patch I found useful. This makes cap, postier,
task,deva and ruth parse their arguments and enable debug output only if
the -D parameter is given.

logs:
ChangeLog:
2005-09-12  Tom Bachmann  <e_mc_h2 <at> web.de>
          * Makefile.am: change the way racin's patch did
          * configure.ac: change the way racin's patch did, add cap header
            linking

postier/ChangeLog:
2005-09-12  Tom Bachmann  <e_mc_h2 <at> web.de>
          * task-user.h: Make it use the interface exported by task
          * Makefile.am: remove task-user.c from the sources (no
            longer needed)
          * ia32-cmain.c: include task-user.h (as task_thread_alloc is now
            inline)

cap/ChangeLog:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane