headers
Bahadir Balban | 1 Jul 09:10
Favicon

Re: [ANNOUNCE] Introducing Codezero

Bas Wijnen wrote:

> I'm not sure if "adding capabilities" to a working system is a proper
> way to get security right.  Security is not something that can be added
> to a program.  It must be at the core, and the design must support it
> from the start.
> 
> If you try to add it, I fear that either it will not work, because there
> are insecure bypasses for secure parts, or it will have bad performance
> because the fast paths of the system aren't used, or both.
>

Hi Bas,

Implementing fine-grained access control mechanism inside the
microkernel should take no more than a week or two. I would imagine all
I would need to do for the first version is to add a per-thread bitmap
structure that controls resources such as the amount of virtual/physical
memory, cpu time, with whom the communication is allowed, which
requests, what type of ipc ... etc.

Securing the existing communication may take some effort, although it
should not be too difficult. There are only 2 servers and a handful of
requests. I think I will have part of the above implemented on the next
version of Codezero. It should also be possible to pass along
capabilities dynamically, though I would imagine most security
permissions to be set up during initialization.

> What I've seen from capability systems, they can be seen by object
> oriented systems as remote object calls.  However, this is not enforced
(Continue reading)

Permalink | Reply | 30 comments |
headers
Bas Wijnen | 1 Jul 16:13
Picon
Favicon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Wed, Jul 01, 2009 at 10:10:25AM +0300, Bahadir Balban wrote:
>> I'm not sure if "adding capabilities" to a working system is a proper
>> way to get security right.  Security is not something that can be added
>> to a program.  It must be at the core, and the design must support it
>> from the start.
>>
>> If you try to add it, I fear that either it will not work, because there
>> are insecure bypasses for secure parts, or it will have bad performance
>> because the fast paths of the system aren't used, or both.
>
> Implementing fine-grained access control mechanism inside the
> microkernel should take no more than a week or two. I would imagine all
> I would need to do for the first version is to add a per-thread bitmap
> structure that controls resources such as the amount of virtual/physical
> memory, cpu time, with whom the communication is allowed, which
> requests, what type of ipc ... etc.

I don't have enough idea about the code to know how good that would
work.  Does your kernel use dynamic memory itself, by the way?  In other
words, can the kernel get out-of-memory errors?

> Securing the existing communication may take some effort, although it
> should not be too difficult. There are only 2 servers and a handful of
> requests. I think I will have part of the above implemented on the next
> version of Codezero.

Yes, that should not be much work.  I would expect no security-features
in the servers, because they simply cannot be contacted by untrusted
(Continue reading)

Permalink | Reply | 7 comments |
headers
Bahadir Balban | 2 Jul 20:20
Favicon

Re: [ANNOUNCE] Introducing Codezero

Hi there,

I have taken a closer look at the existing Hurd implementation. It looks
very much like what I had in mind when meaning "microkernel based OS
using plan 9 design principles". In particular, Plan 9 introduces:

* Private namespaces i.e. each process having its own view of the
filesystem.
* Services as file servers (e.g. tcp/ip stack, ftp service, windowing
system, console etc.)
* Union filesystems i.e. multiple filesystem trees merged at a single path.

Essentially a Hurd translator setup with settrans is what a file-based
server does when mounted in Plan 9.

Plan 9 differentiates by implementing a monolithic kernel, and Hurd,
having a microkernel design comes closer to what I plan to do. Having
said that, let me get into your arguments:

Bas Wijnen wrote:
> Hi,
> 
> 
> I don't have enough idea about the code to know how good that would
> work.  Does your kernel use dynamic memory itself, by the way?  In other
> words, can the kernel get out-of-memory errors?
> 

Currently, we do have this. There is a very rigorous memory allocation
policy though. Page tables, thread control blocks and space structures
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ludovic Courtès | 4 Jul 01:40
Picon

Re: [ANNOUNCE] Introducing Codezero

Hi,

Bahadir Balban <bahadir <at> l4dev.org> writes:

[...]

> One could have "ctl" and "data" files as in Plan 9, to implement
> driver control and data flow (or use extensible file attributes)
>
> File-based API should work for most services such as communication
> protocols, drivers, console etc. Please elaborate on why you oppose it.

I suppose Bas is referring to the fact that Plan 9 ends up doing a lot
of possibly costly marshalling/unmarshalling on `ctl' nodes (see [0] for
an example).

Compare this with the Hurd/MiG approach where an RPC is encoded in a
compact binary form, which is more amenable to optimizations.

Thanks,
Ludo'.

[0] http://swtch.com/usr/local/plan9/src/cmd/auth/factotum/ctl.c
Permalink | Reply | 2 comments |
headers
James Collier | 5 Jul 03:08
Picon

Re: Viengoos IPC

Hello again,
I've continued playing with IPC on Viengoos.
I've think had some success but I'd run up against what feels like a
brick wall now.
I have a child thread sending a message to the parent (main) thread.
I start the child thread with pthread_create, except it apparently never
starts.

Following is the child thread code for sending the IPC:
<code>
void
hello_sender(int argc, char** argv)
{
  if(argc != 1) pthread_exit(NULL);

  vg_addr_t recv_messenger =
	 vg_addr_chop(VG_PTR_TO_ADDR(argv[0]),PAGESIZE_LOG2);
  struct hurd_message_buffer *mb = hurd_message_buffer_alloc();

  s_printf("running second thread.\n");
  vg_send(VG_IPC_RECEIVE_SET_THREAD_TO_CALLER |
          VG_IPC_RECEIVE_SET_ASROOT_TO_CALLERS,
          /*activity*/VG_ADDR_VOID, recv_messenger, mb->sender,
          VG_PTR_TO_PAGE(mb->request));

  hurd_message_buffer_free(mb);
  s_printf("Finished child thread\n");
  pthread_exit(NULL);
}
</code>
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Collier | 5 Jul 04:05
Picon

Re: Viengoos IPC

Apologies, I forgot to post the output from Viengoos:

<output>
hieronymus (811000):main:316:(0x471c72): hello: 0s delayed start,
starting in -6 s
hieronymus (811000):main:323:(0x471c72): Starting hello
In cmain
in crt0 (6e3000):storage_init:968:(0x4105e8): 3 folios, 273 objects
used, 115 free objects
viengoos (0):ager:615:(0xffffffff80417eae): 5: 106 mb of 109 mb (97%)
free
  laundry: 0 bytes; 1168 kb active (0 bytes new); 1592 kb inactive (212
kb new), 972 kb shared unmapped
: 3000-7dfff
: 7f000-7ffff
: 200000-3fffff
: 4aa000-6a9fff
: 700000-700fff
: 702000-7fffffffffffffff

/**********/
Running messenger...
viengoos (0):thread_init:152:(0xffffffff80410c99): Creating thread 4cc
/**********/

viengoos (0):ager:615:(0xffffffff80417eae): 6: 106 mb of 109 mb (97%)
free
  laundry: 0 bytes; 1728 kb active (0 bytes new); 1500 kb inactive (108
kb new), 0 bytes shared unmapped
viengoos (0):ager:615:(0xffffffff80417eae): 7: 106 mb of 109 mb (97%)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bas Wijnen | 5 Jul 11:38
Picon
Favicon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Sat, Jul 04, 2009 at 01:40:03AM +0200, Ludovic Courtès wrote:
> > One could have "ctl" and "data" files as in Plan 9, to implement
> > driver control and data flow (or use extensible file attributes)
> >
> > File-based API should work for most services such as communication
> > protocols, drivers, console etc. Please elaborate on why you oppose it.
> 
> I suppose Bas is referring to the fact that Plan 9 ends up doing a lot
> of possibly costly marshalling/unmarshalling on `ctl' nodes (see [0] for
> an example).

I don't really know much about Plan 9, so this isn't what I meant.
However, I had heard this and don't like that either.  But it's not an
essential part of the "all communication is done on file-style objects"
idea.

What I meant is that there are at least two major modes of
communication.  One is stream-based and is used for files and tcp/ip,
for example.  When writing or reading, a sent package may end up as two
received packets and vice versa.

The other mode is with packets.  Udp/ip uses this, and so do most device
drivers.  For files, something similar is possible when using mmap.  For
general communication between threads, I would expect this to be the
main mode, in fact.  As a comparison, in the usb protocol, there is:
- interrupt and control traffic: packet-based, small chunks.
- bulk traffic: packet-based, but often interpreted as a stream.  Larger
  chunks.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bahadir Balban | 7 Jul 10:19
Favicon

Re: [ANNOUNCE] Introducing Codezero

Bas Wijnen wrote:
> Hi,
> 
> On Sat, Jul 04, 2009 at 01:40:03AM +0200, Ludovic Courtès wrote:
>>> One could have "ctl" and "data" files as in Plan 9, to implement
>>> driver control and data flow (or use extensible file attributes)
>>>
>>> File-based API should work for most services such as communication
>>> protocols, drivers, console etc. Please elaborate on why you oppose it.
>> I suppose Bas is referring to the fact that Plan 9 ends up doing a lot
>> of possibly costly marshalling/unmarshalling on `ctl' nodes (see [0] for
>> an example).
> 
> I don't really know much about Plan 9, so this isn't what I meant.
> However, I had heard this and don't like that either.  But it's not an
> essential part of the "all communication is done on file-style objects"
> idea.
> 
> What I meant is that there are at least two major modes of
> communication.  One is stream-based and is used for files and tcp/ip,
> for example.  When writing or reading, a sent package may end up as two
> received packets and vice versa.
> 
> The other mode is with packets.  Udp/ip uses this, and so do most device
> drivers.  For files, something similar is possible when using mmap.  For
> general communication between threads, I would expect this to be the
> main mode, in fact.  As a comparison, in the usb protocol, there is:
> - interrupt and control traffic: packet-based, small chunks.
> - bulk traffic: packet-based, but often interpreted as a stream.  Larger
>   chunks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
olafBuddenhagen | 10 Jul 03:14
Picon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Wed, Jul 01, 2009 at 10:10:25AM +0300, Bahadir Balban wrote:
> Bas Wijnen wrote:

> Implementing fine-grained access control mechanism inside the
> microkernel should take no more than a week or two. I would imagine
> all I would need to do for the first version is to add a per-thread
> bitmap structure that controls resources such as the amount of
> virtual/physical memory, cpu time, with whom the communication is
> allowed, which requests, what type of ipc ... etc.

Isn't most of that actually possible with standard L4?...

However, this is *not* sufficient. Sure, it is fine for embedded
systems, which live in a very statical environment. It has been done
before -- a number of multiserver systems exist that are quite
successful in the embedded market.

However, for a general-purpose operating system, we need much more
dynamic permission and resource management. This is where the real
problems lie -- the major challange we face with the Hurd; and in fact
the major challenge in any attempt to create a general-purpose
multiserver operating system.

-antrik-
Permalink | Reply | 21 comments |
headers
olafBuddenhagen | 8 Jul 02:35
Picon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Thu, Jul 02, 2009 at 09:20:31PM +0300, Bahadir Balban wrote:
> Bas Wijnen wrote:

> I have taken a closer look at the existing Hurd implementation. It
> looks very much like what I had in mind when meaning "microkernel
> based OS using plan 9 design principles".

Not really. There *are* some similarities regarding the file system
handling -- but there are also very fundamental differences between Plan
9 and the Hurd, thich go far beyond monolithic vs. microkernel design:

- The Hurd is UNIX (POSIX) compatible

- While (almost) all services are attached to the file system tree, not
  all services actually export a file system interface!

  Personally, I advocate using FS-based interfaces as much as possible.
  Yet, there are some cases where they get very arward and/or
  inefficient, and domain-specific interfaces simply make a lot more
  sense.

  Also, some Hurd services are indeed used to implement the file systems
  in the first place -- they work *below* the FS level, and obviously
  can't use an FS interface!

- File systems are completely decentralized -- clients always talk to
  the FS servers directly, without any central VFS layer. (I don't think
  that's the case in Plan 9?)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane