keithjarrin@gmail.com ha scritto:
> Is there any interest in pursuing through the OLPC activity a more
> secure platform for everyone?

It looks like there is some interest for Minix as a secure platform:

http://www.cis.syr.edu/%7Ewedu/seed/Labs/Capability/

In this case they are interested in developing a capability-based model,
not a virtualization-based one.

> BTW - I'm interested in helping the MINIX project - I have heavy
> device driver
> experience and would like to help craft a good architecture to run pre-
> existing
> Linux/BSD device drivers.

Very good idea. This would ease a lot the development of a "usable"
minix3 "distro".

CU

--

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

"Se un uomo non ha scoperto un motivo per cui morire, non ha ragione di
vivere."
-- Martin Luther King

On May 11, 2:16 am, Alessandro Bottoni
wrote:
> keithjar...@gmail.com ha scritto:
>
> > Is there any interest in pursuing through the OLPC activity a more
> > secure platform for everyone?
>
> It looks like there is some interest for Minix as a secure platform:
>
> http://www.cis.syr.edu/%7Ewedu/seed/Labs/Capability/
>
> In this case they are interested in developing a capability-based model,
> not a virtualization-based one.
>
> > BTW - I'm interested in helping the MINIX project - I have heavy
> > device driver
> > experience and would like to help craft a good architecture to run pre-
> > existing
> > Linux/BSD device drivers.
>
> Very good idea. This would ease a lot the development of a "usable"
> minix3 "distro".
>
> CU
>
> --
>
> Alessandro Bottoni
> Website:http://www.alessandrobottoni.it/
>
> "Se un uomo non ha scoperto un motivo per cui morire, non ha ragione di
> vivere."
> -- Martin Luther King



Another approach to virtualization would be to get the Minux kernel to
support Kernel Virtual Machine (KVM); all the user space operating
system services (file system, device drivers, etc) would be like a
'Dom0' in Xen.

The reason why I mention this is that we would
want to take advantage of Intel's Vt-d capability to isolate device
drivers away from the rest of the platform.

On May 11, 8:49 am, kmj wrote:
> On May 11, 2:16 am, Alessandro Bottoni
>
>
>
> wrote:
> > keithjar...@gmail.com ha scritto:
>
> > > Is there any interest in pursuing through the OLPC activity a more
> > > secure platform for everyone?
>
> > It looks like there is some interest for Minix as a secure platform:
>
> >http://www.cis.syr.edu/%7Ewedu/seed/Labs/Capability/
>
> > In this case they are interested in developing a capability-based model,
> > not a virtualization-based one.
>
> > > BTW - I'm interested in helping the MINIX project - I have heavy
> > > device driver
> > > experience and would like to help craft a good architecture to run pre-
> > > existing
> > > Linux/BSD device drivers.
>
> > Very good idea. This would ease a lot the development of a "usable"
> > minix3 "distro".
>
> > CU
>
> > --
>
> > Alessandro Bottoni
> > Website:http://www.alessandrobottoni.it/
>
> > "Se un uomo non ha scoperto un motivo per cui morire, non ha ragione di
> > vivere."
> > -- Martin Luther King
>
> Another approach to virtualization would be to get the Minux kernel to
> support Kernel Virtual Machine (KVM); all the user space operating
> system services (file system, device drivers, etc) would be like a
> 'Dom0' in Xen.
>
> The reason why I mention this is that we would
> want to take advantage of Intel's Vt-d capability to isolate device
> drivers away from the rest of the platform.

One more thing, I used to sit on the Trusted Computing Group (TCG)
committees for virtualization and infrastructure. TCG is looking for
ways to demonstrate 'complete worked examples' and 'use cases'. I
can't think of anything better than a 'Trusted Computing
Minux' (TCMinux) supporting worked examples for the trusted platform
module and network attestation.

On May 11, 7:44 am, keithjar...@gmail.com wrote:
> Is there any interest in pursuing through the OLPC activity a more
> secure platform for everyone?
>
> The basic architecture is a sound foundation for secure computing. Has
> anyone
> considered working with the L4 microkernel folks to include
> virtualization in this
> architecture? Transitioning the MINIX3 kernel to that of a hypervisor
> using Intel
> TxT and AMD Pacifica instructions would be a good move.
>
> BTW - I'm interested in helping the MINIX project - I have heavy
> device driver
> experience and would like to help craft a good architecture to run pre-
> existing
> Linux/BSD device drivers.

Do you mean effectively enabling Minix3 to be a VMM? That would be
really, really cool. I'd love to help test such a thing and it would
be a great learning experience.

Beyond trusted computing, this would help demonstrate that 'reliable
means never needing to reboot'.

good_idea ++;

Cheers,
--Tim

> The basic architecture is a sound foundation for secure computing. Has
> anyone
> considered working with the L4 microkernel folks to include
> virtualization in this
> architecture? Transitioning the MINIX3 kernel to that of a hypervisor
> using Intel
> TxT and AMD Pacifica instructions would be a good move.

I think adding virtualization to the Minix kernel would go counter to
some of its objectives. It would complicate the kernel, making it less
useful for education and less of a true microkernel. The operating
system as a whole would most likely grow, making it less suitable for
small embedded devices.

Although reliability is indeed an important goal of Minix, the approach
to reliability is the microkernel rather than virtualization. In
principle an effective separation between processes, and moving stuff
out of the kernel should be sufficient without virtualization (although
maybe the virtualization instructions could be used to make this
separation more effective; I do not know enough of them to judge this).

I would like to note that user-level virtualization will be available
in Minix, as I have ported Qemu as a part of my master's project and
will make it available in the future. Although slower, this makes at
least some of the advantages of virtualization available to Minix.

--
With kind regards,
Erik van der Kouwe

Erik van der Kouwe
> I think adding virtualization to the Minix kernel would go counter to
> some of its objectives. It would complicate the kernel, making it less
> useful for education and less of a true microkernel. The operating
> system as a whole would most likely grow, making it less suitable for
> small embedded devices.

You are right. Should Minix3 take the same development path of Linux and
BSD (that is: a large, good4everything system), it would loose a large
part of its appeal. It has to be small, simple, fast, modular,
"readable" and efficient to be "different" and appealing.

> Although reliability is indeed an important goal of Minix, the approach
> to reliability is the microkernel rather than virtualization. In
> principle an effective separation between processes, and moving stuff
> out of the kernel should be sufficient without virtualization (although
> maybe the virtualization instructions could be used to make this
> separation more effective; I do not know enough of them to judge this).

You are right again. Minix3 has already chosen its personal way to
reliability and it would make little sense to have TWO different and
overlapping models.

> I would like to note that user-level virtualization will be available
> in Minix, as I have ported Qemu as a part of my master's project and
> will make it available in the future. Although slower, this makes at
> least some of the advantages of virtualization available to Minix.

Good news. Thanks for your contribution.

CU
--

Alessandro Bottoni
Website: http://www.alessandrobottoni.it/

"How wonderful that we have met with a paradox. Now we have some hope of
making progress."
-- Niels Bohr