headers
Matthieu Lemerre | 2 Jul 18:39
Picon
Favicon

IO-Flexpage support added


Hi,

This patch adds IO-Flexpages support to the Hurd.  For those who don't
know, IO-Flexpage is the way to give to tasks access to IO-ports on
IA32 and AMD64 machines, and works like Flexpage (with limitations).
It is part of L4 X.2 spec and was implemented recently in pistachio
CVS.

This patch makes wortel request a IOFpage containing all IO ports from
sigma0, and makes deva ask it back from wortel.  Future device drivers
(and regular applications?) will then receive specific io ports from
deva when they ask for it.

One little thing was missing from sigma0 to get it working; I sent a
patch that hopefully the L4ka team will integrate (or a better one).
I attach it for those who would want to try.

I added support for both IO-Flexpage and no IO-Flexpage in the kernel
at first, and I had to factorize wortel/sigma0.c a little.  Then
Marcus told me we should simply drop support for kernel without
IO-Flexpages support, but I kept the factorization anyway.  I think
it's pretty harmless.

Thanks,
Matthieu

deva/Changelog:

2005-07-02  Matthieu Lemerre  <racin <at> free.fr>
(Continue reading)

Permalink | Reply | 0 comments |
headers
NePat | 9 Jul 17:14
Picon

Hurd-L4 : Architecture Questions


		Hello,
  I've spend much time in reading documentation on L4-Hurd, i read some code , 
i also read some mails in the mailing list, and i have some questions to ask 
(excuse my poor english :) ) :

1 - Trusted process ?
	There's lots of things and thought about, but i don't really get the thing. 
	On what is based the amount of trust provide to a process by a server ? Why 
	it can't be enough to trust the owner (user) of a process ?
2 - SMP are'nt thinked ?
	I don't find anything about SMP ans L4-Hurd. Altought the L4 pistachio seems
	to be designed in such a way. And , the heavily muti-threaded conception
	of Hurd-L4 is directly interested in SMP. And more, the futur, by the limit
	on electronics size, is to the SMP. So ...

It seems that the design changes his way to a more centralized system ( with 
cap server and notification server, perhaps there's the same ), but in SMP 
architecture centralisation is a bad thing ( i think ), the things has to be 
as much as possible local, so are the reason to change the way so 
unbreakable ? ( and i don't speak about overhead costs ).

Thanks,
Permalink | Reply | 2 comments |
headers
NePat | 9 Jul 19:05
Picon

Re: Hurd-L4 : Architecture Questions

ness, wrote :
> [I'm not a expert, so be careful]
I'm not an expert also.

> A thread will be able to get a capability from an authentication server so 
> we can implement posix compilant auth. 

OK, the Auth server will garantee servers that the process is "trustable". I'm 
ok with this. My question is : So what the need for Marcus Bringman to manage 
such IPC protocol based on the fact that client are not "trustable" ? Don't 
they juste have to ask the auth server if they want to know about the 
process ?

> 2.:
> Noone says these can't create multible threads and be executed multiple 
times. 
I'm not sure to understand. Did you say that core servers can't have multiple 
instance on different processor ? If they can't i think it's a great pain for 
the system : Imagine a set of processors  P1, P2, .. Pn. If there is only one 
instance of the memory server on the system there while be : 
   - challenge for process to access it
   - dificulties to communicate with it 
	( cause it is on an other Processor -> processor cache is not the same -> 
	need to communicate through the RAM)
   - lack of time garantees that lead to impossibility of a real time system

Thanks,
Permalink | Reply | 0 comments |
headers
ness | 9 Jul 18:42
Picon
Gravatar

Re: Hurd-L4 : Architecture Questions

[I'm not a expert, so be careful]
1.:
What is the owner of a process? The chief of it's clan? It's manager?
Well, in hurd everything works on capabilities. A process doesn't have a
owner in the way you know it from linux or so. A thread will be able to
get a capability from an authentication server so we can implement posix
compilant auth. Or you create an other authentication mechanism, if you
like it. You see, doing this with owners would not be a good idea, since
it doesn't collaborate with the capability philosophy and you wouldn't
even know what auth-server to ask.
2.:
Well, I think you need some core servers. Noone says these can't create
multible threads and be executed multiple times. We need them, because
we need some servers that are trusted always. The only servers everyone
has to trust are these core servers (since these are started by the
kernel and can do or not do what they want).

NePat wrote:
> 		Hello,
>   I've spend much time in reading documentation on L4-Hurd, i read some code , 
> i also read some mails in the mailing list, and i have some questions to ask 
> (excuse my poor english :) ) :
> 
> 1 - Trusted process ?
> 	There's lots of things and thought about, but i don't really get the thing. 
> 	On what is based the amount of trust provide to a process by a server ? Why 
> 	it can't be enough to trust the owner (user) of a process ?
> 2 - SMP are'nt thinked ?
> 	I don't find anything about SMP ans L4-Hurd. Altought the L4 pistachio seems
> 	to be designed in such a way. And , the heavily muti-threaded conception
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Negre | 9 Jul 21:48
Picon
Favicon

Re: Hurd-L4 : Architecture Questions

ness, wrote :
> I's because of the system doesn't know about the auth server (well it
> knows about it, because both are a integral part of the system, but this
> would break the design).

 What about the design ? I understand in the L4-Hurd thread that the "trust 
problem" is such big that a cap-server have to be construct. Sush server that 
does'nt break the design too ? The first capabilities protocol did'nt need a 
cap server. Now every single capabilitie call have to pass through the cap 
server. Does'nt it's better if the server acquire trust on a client with lony 
one access to the auth server ? And more, the communications between the 
client and the server will be locale to the processor ( if the 2 process are 
local indeed ), i think that's better for a SMP architecture ( less cache 
synchronisations ).

> >>2.:
> Well, I tried to say that it's no problem for these server to create
> multiple threads. And the kernel (pistachio) will arrange them on the
> multiple processors if available.

I got it, that's fine.

Thanks, Negre Patrick
Permalink | Reply | 0 comments |
headers
Matthieu Lemerre | 10 Jul 22:00
Picon
Favicon

Re: Hurd-L4 : Architecture Questions

NePat <nepatrick <at> wanadoo.fr> writes:

> 		Hello,

Hi,

(and sorry for the late answer, but we were all in LSM)
> 
>   I've spend much time in reading documentation on L4-Hurd, i read
> some code , i also read some mails in the mailing list, and i have
> some questions to ask (excuse my poor english :) ) :
>
> 1 - Trusted process ?
> 	There's lots of things and thought about, but i don't really get the thing. 
> 	On what is based the amount of trust provide to a process by a server ? Why 
> 	it can't be enough to trust the owner (user) of a process ?

This question is in fact not specific to the L4 port of the Hurd.
Basically, the Hurd is designed so that if you communicate with a
server which is a malicious program, i.e. it will do anything it can
to annoy you (like trying to freeze you), the amount of annoyement
that it can do is limited.

For instance, if you are using emacs and opening a file located on a
filesystem provided by a translator runned by another user, and this
translator is malicious, all that it can do is not respond to you, and
you can cancel the operation and emacs will never freeze or crash.

The server also needn't to trust the client. So we can have
communication between a client and a server and no one trust the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ludovic Courtès | 12 Jul 15:05
Picon
Picon
Favicon

On trusting its parent process

Hi,

LSM talks by Shapiro (on EROS and Coyotos) and Forsyth (on Plan 9) were
quite insightful.  I just found this followup:
http://www.coyotos.org/pipermail/coyotos-dev/2005-July/000138.html .

What strikes me in this message is this:

  1. The *only* way that a process in plan-9 can obtain a capability is
  from its parent. This is a problem if the capability refers to important
  state and the parent is untrusted. Consider, for example, that the
  "passwd" program can no longer trust the content of /etc/passwd, because
  it has no way to know if it is receiving an authentic copy of the file.

  [...]

  This differs very strongly from the status in EROS/Coyotos, where
  *authentication* capabilities are not considered to be "holes" for
  purposes of confinement. An implication of this is that the capability
  which answers the question "Is this capability a capability to an
  authentic X object" can be widely distributed, and can come to the user
  in a way that the parent process cannot interfere with.

In the Hurd, processes get capabilities to the root filesystem, to
`auth' and friends from their parent process.  This is very convenient
because it allows to run processes in a "sandbox".  OTOH, this makes it
impossible for a process to make sure it is talking to "authentic"
servers, as in the Plan 9 case above.

Now, what does "authentic" mean in a system designed in such a way that
(Continue reading)

Permalink | Reply | 9 comments |
headers
ness | 12 Jul 16:10
Picon
Gravatar

Quoting problems (or: why doesn't my new configure script work?)

My new idl4 interface and features seem to work. Now I wanted to change
the configure.ac to find idl4, set IDL4FLAGS and test whether idl4 is
new enough. One of my changes requires that one gives the compiler call
to idl4, as ONE parameter. My try looks like that:
(CFLAGS, CC and IDL4 are legal)

IDL4FLAGS="$IDL4FLAGS -i V4_GNU -p generic -T -C \"$CC $CFLAGS\""
echo -n "checking for idl4 -l -i V4_GNU... "
$IDL4 $IDL4FLAGS -l -c test.idl
if test -e test_client.h;then
echo yes
rm test_client.h
else
echo 'Your version of idl4 is outdated, see README.idl4!'
exit 1
fi

But it doesn't work. It looks like idl4 doesn't get the compiler call
quoted.
Cleartext: The line $IDL4 $IDL4FLAGS -l -c test.idl should be expanded
to e.g. idl4 -i V4_GNU -p generic -T -C "gcc -O3 -std=gnu99" -c test.idl
but gets expanded to idl4 -i V4_GNU -p generic -T -C gcc -O3
-std=gnu99 -c test.idl. Why?
I only ask here since I got no answer elsewhere
Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 12 Jul 18:54
Picon
Favicon

Re: Quoting problems (or: why doesn't my new configure script work?)

At Tue, 12 Jul 2005 16:10:08 +0200,
ness <e_mc_h2 <at> web.de> wrote:
> 
> My new idl4 interface and features seem to work. Now I wanted to change
> the configure.ac to find idl4, set IDL4FLAGS and test whether idl4 is
> new enough. One of my changes requires that one gives the compiler call
> to idl4, as ONE parameter. My try looks like that:
> (CFLAGS, CC and IDL4 are legal)
> 
> IDL4FLAGS="$IDL4FLAGS -i V4_GNU -p generic -T -C \"$CC $CFLAGS\""
> echo -n "checking for idl4 -l -i V4_GNU... "
> $IDL4 $IDL4FLAGS -l -c test.idl

You need eval.

$ export abc='1  "2  3"  4'
$ eval "echo $abc"
1 2  3 4

Yeah, took me a while, too ;)

Thanks,
Marcus
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 12 Jul 18:36
Picon
Favicon

Re: On trusting its parent process

Hi,

I wish I knew Plan 9 and EROS better, so I could answer your question.
I don't understand what Jonathan Shapiro is saying in the mail you
refer to, so it's very hard to comment.

>   1. The *only* way that a process in plan-9 can obtain a capability is
>   from its parent.

[...]

>   This differs very strongly from the status in EROS/Coyotos, where
>   *authentication* capabilities are not considered to be "holes" for
>   purposes of confinement. An implication of this is that the capability
>   which answers the question "Is this capability a capability to an
>   authentic X object" can be widely distributed, and can come to the user
>   in a way that the parent process cannot interfere with.

So what would such a way be?  The only way I see is by a kernel system
call which performs right amplification, and grants the process the
authority to authenticate capabilities.  Maybe this is how it is done
in EROS (I vaguely remember something like this, but the details
escape me).

> In the Hurd, processes get capabilities to the root filesystem, to
> `auth' and friends from their parent process.

Not quite right.  They get their capabilities from the parent.  There
are some capabilities they can get from Mach: task-self, thread-self.
But the others are inherited from the parent process.  The "root
(Continue reading)

Permalink | Reply | 6 comments |

Gmane