headers
R. Koot | 1 Jan 16:22
Picon

Re: Unmapping fpages

Espen Skoglund wrote:

>[R Koot]
>  
>
>>This is exectly what my first reply was, but the problem is that
>>we're talking about the physmem server, and that memory would
>>*always* be remapped into another adresses space soon after being
>>unmapped (into creditcard_and_password_storage_serv for example). If
>>the original server didn't do an l4_unmap it would now be able to
>>read the memory of that other server.
>>    
>>
>
>In which case the physmem server would unmap the memory from *all*
>spaces before giving it out to creditcar_and_password_storage_serv.
>Unmapping the memory from all servers is no problem.
>  
>
But this would at best have a high (and maybe unnecessary) performance 
penalty associated with it. The problem here isn't that it's can't be 
done the way it is now, it's just that there might be a better way (or 
maybe not, it would be necessary to investigate both the benefits and 
cost first). The main problem with the current implementation is that it 
creates interdependencies between servers (maybe I should be more 
careful in my wording and say "it's more/very/too difficult to design a 
system which there aren't any with the current L4_Unmap implementation, 
but I won't). Interdependencies make the system complex. more difficult 
to analize, cause performance and scalability problems, cause hidden 
bugs and, as Neal mentioned, open up the possibility of DoS attacks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
R. Koot | 1 Jan 16:27
Picon

Re: Unmapping fpages

R. Koot wrote:

> I think "loads of 'fixes'" *would* apply to this case (adding support 
> for ELF TLS would IMHO). L4_Unmap is the only syscall that hasn't 
> changed since v2, I believe it is showing some defects and it should 
> be considered to fix this in the kernel instead of user-mode.

The first "would" should (obviously) be a "doesn't".

Ruud
Permalink | Reply | 0 comments |
headers
Matthieu Lemerre | 6 Jan 00:51
Picon
Favicon

Some libl4 patches


Hello,

I had to make some patches to libl4 to get string message passing works:

in ia32/vregs.h: There was some problem with Buffer register
loading/storing (basically, it didn't worked because the data were
processed backward)

in ipc.h:

functions _L4_msg_buffer_append_simple_rcv_string and
_L4_msg_buffer_append_rcv_string:

There was a single | instead of ||, and , as || is yet used in
_L4_accept_strings, I put || to normalize.

They also did not work because of a do ... while done instead of a
while: the first bytes of the message buffer were never used.

So I propose the folowing: a call to l4_msg_buffer_clear would set
both the first and the second word to 0, and we test whether the
second word is set or not for knowing whether or not there is already
a string item in the message buffer (because putting one would set
this second word to the address of the string or substring ptr, thus
overriding the 0)

However, there is a problem if we can use the null pointer as the send
or receive address of a string.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Neal H. Walfield | 6 Jan 10:31

Re: Some libl4 patches

Hi Matthieu,

I haven't looked at your patch in detail yet but I will.

Just to let you know, right now we do not use string items at all in
the Hurd.  This doesn't mean that we won't nor does it mean that we
don't want libl4, it just means that as you have observed, the code is
not well tested.

Next, please supply a change log entry.  For an example of a change
log entry, look in the ChangeLog files and in the GNU Coding
Standards.  It is important that this is included.

Also, can you please fix your indentation to be consistent with ours.
For instance, in the last hunk of your patch, you have:

	+  if(msg_buffer[1])

This should be:

	+  if (msg_buffer[1])

Note the space.  All of this is covered in the GNU coding standards
(and if you use emacs, tab helps a lot with indentation).

A very minor nit: please use -p when generating diffs.  This makes
them slightly easier to read.

Finally, for something a bit more positive: your explanation of what
is wrong is excellent and a text like this should accompany all
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 6 Jan 17:03
Picon
Favicon

Re: Booting

At Fri, 31 Dec 2004 00:43:13 +0100,
Bas Wijnen <shevek <at> fmf.nl> wrote:
> Currently my system boots until task.  I still haven't tried Marcus' 
> deva things.  Anyway, I was wondering what more is needed to boot the 
> system.
> 
> I would expect that after task, a ramdisk can be used as rootfs, from 
> which deva can be started.

The idea is that the module after deva is the deva initial driver
archive, which is a bit like linux's initrd.  It would contain all
drivers needed before the root filesystem is up.

I always planned to use a fake driver in there which would take its
filesystem data from the initial driver archive itself.  OTOH, a
simple IDE driver doesn't seem to complicated after all, so that is
also a possibility.

> I know the idea is to use a working deva for 
> starting rootfs, but that would put limits on the deva boot (with a root 
> fs, it can consist of normal processes, as they have everything they 
> need: physmem, task, and rootfs).  Since a ramdisk wouldn't need any 
> device drivers, I don't see a problem with it.

I don't understand the beginning of the sentence.  The root filesystem
server would be started by wortel, and is passed as the last module in
the grub configuration.  The driver archive for deva should only
contain deva drivers, which are hurd-independent.  The root filesystem
is a hurdish server task and thus outside of the deva archive.  But it
was my plan to make it use a deva ramdisk driver.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marcus Brinkmann | 6 Jan 17:41
Picon
Favicon

Re: Some libl4 patches

Hi,

I'll beat Neal to the punch.

At Thu, 06 Jan 2005 00:51:29 +0100,
Matthieu Lemerre <racin <at> free.fr> wrote:
> I had to make some patches to libl4 to get string message passing works:

Great, thanks a lot.  We will guide you through the usual peer review... ;)

> in ia32/vregs.h: There was some problem with Buffer register
> loading/storing (basically, it didn't worked because the data were
> processed backward)

Yes.  The same problem exists in the powerpc port.

> 
> in ipc.h:
> 
> functions _L4_msg_buffer_append_simple_rcv_string and
> _L4_msg_buffer_append_rcv_string:
> 
> There was a single | instead of ||, and , as || is yet used in
> _L4_accept_strings, I put || to normalize.

Ok.  There is no functional change by this, but it gives more
information to the compiler if we use ||.

> They also did not work because of a do ... while done instead of a
> while: the first bytes of the message buffer were never used.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marcus Brinkmann | 6 Jan 17:57
Picon
Favicon

Re: Some libl4 patches

At Thu, 06 Jan 2005 17:41:44 +0100,
Marcus Brinkmann wrote:
> Indeed, so your fix is invalid.  0 is a perfectly fine address for a
> string buffer, as far as L4 is concerned.  There is another

There is nothing missing here.  Just ignore the words "There is
another".

> So, you would have to check the first word of the string item.  This
> is still flawed, but in a more subtle way, as even a string buffer of

Thanks,
Marcus
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 6 Jan 17:54
Picon
Favicon

Re: Contribution to the Hurd on L4

At Thu, 30 Dec 2004 19:51:17 +0100,
Matthieu Lemerre <racin <at> free.fr> wrote:
> Neither task nor deva was started for me. I recompiled a l4 kernel and
> it worked. (Maybe I was using the old patch for pistachio 0.2)

If your grub config is right, and deva is not started, then you should
look at using the latest pistachio as required in the README.  deva
does have a cheesy kbd driver which echoes kbd input, and ESC will
trigger int $3 to get you into the debugger if you enabled the trap in
the configuration of pistachio.  That should give you a hint if it is
running.

> It works well when I omit the   l4_msg_append_simple_string_item (msg, string_item);
> line, but fail with the e field of the IPC error code set to 4
> otherwise. After a while of hard debugging session (I have to reboot,
> bochs won't run on my old PC), I decided to flood the mailing list a little more :)
> 

By now you found problems in libl4, so I didn't review your code.  You
could try qemu btw, which works fine for me when I run it within a gdb
session (don't ask).

> I have some questions regarding the libl4 interface:
> 
> -How to create a new string item with the GNU interface? The
>  _L4_string_item function does not have a GNU "name".

Yes, it is missing.  Want to send in a patch?

> -What is the bug in _L4_msg_get_string_item?
(Continue reading)

Permalink | Reply | 11 comments |
headers
Matthieu Lemerre | 6 Jan 21:22
Picon
Favicon

Re: Contribution to the Hurd on L4

Marcus Brinkmann <marcus.brinkmann <at> ruhr-uni-bochum.de> writes:

> At Thu, 30 Dec 2004 19:51:17 +0100,
> Matthieu Lemerre <racin <at> free.fr> wrote:
>> Neither task nor deva was started for me. I recompiled a l4 kernel and
>> it worked. (Maybe I was using the old patch for pistachio 0.2)
>
> If your grub config is right, and deva is not started, then you should
> look at using the latest pistachio as required in the README.  deva
> does have a cheesy kbd driver which echoes kbd input, and ESC will
> trigger int $3 to get you into the debugger if you enabled the trap in
> the configuration of pistachio.  That should give you a hint if it is
> running.

I was in fact meaning that I managed to make it work.

I looked at it, and I was wondering when work on the device driver
framework could begin? I think it would require some work and I would
be happy to contribute :) (but I would also be happy to contribute to
any other thing)

>
>> It works well when I omit the   l4_msg_append_simple_string_item (msg, string_item);
>> line, but fail with the e field of the IPC error code set to 4
>> otherwise. After a while of hard debugging session (I have to reboot,
>> bochs won't run on my old PC), I decided to flood the mailing list a little more :)
>> 
>
> By now you found problems in libl4, so I didn't review your code.  You
> could try qemu btw, which works fine for me when I run it within a gdb
(Continue reading)

Permalink | Reply | 10 comments |
headers
Matthieu Lemerre | 6 Jan 22:24
Picon
Favicon

Re: Some libl4 patches

Hi,

*To answer to Neal:

> Next, please supply a change log entry.  For an example of a change
> log entry, look in the ChangeLog files and in the GNU Coding
> Standards.  It is important that this is included.

Should I provide it in the patch or in a separate file (tell me what's
easier for you)

>
> Also, can you please fix your indentation to be consistent with
>ours.  For instance, in the last hunk of your patch, you have:
>
> 	+  if(msg_buffer[1])
>
> This should be:
>
> 	+  if (msg_buffer[1])
>
> Note the space.  All of this is covered in the GNU coding standards
> (and if you use emacs, tab helps a lot with indentation).
>

I (of course?) use emacs, and try to follow the GNU coding standards,
but it is true that I never took the habit to put a space between a
function name and its parenthesis (I wrote a function to do it for me,
but it was lost in a recent hard drive failure :().
(Continue reading)

Permalink | Reply | 3 comments |

Gmane