l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Broken dream of mine :(


From: Michal Suchanek
Subject: Re: Broken dream of mine :(
Date: Wed, 4 Nov 2009 12:39:05 +0100

2009/10/28 Jonathan S. Shapiro <address@hidden>:
> On Tue, Oct 27, 2009 at 8:05 PM, <address@hidden> wrote:
>>
>> Not sure what you are trying to say here. Both Coyotos an Viengoos do
>> resource management in userspace components...
>
>
> Correct.
>
>>
>> , but need the right kernel
>> primitives to be able to account resource usage and enforce the
>> distribution; and as the models differ quite a lot, so do the necessary
>> primitives AIUI.
>
> I don't think this is correct. Concrete example or evidence, please?
>
>>
>> > I don't think Neal made a bad choice, going with an established kernel
>> > (pistachio) as a base makes more sense than getting roped into
>> > maintaining one yourself (which may have happened had he used
>> > Coyotos), all things being equal.
>>
>> L4 was only (mis-)used as a hardware abstraction in the prototype
>> implementation of Viengoos. There is now also a proper native x86_64
>> implementation. It isn't based on L4 anymore -- and conceptually, never
>> really was.
>
>
> Neal made a good choice prototyping ideas on a pre-existing substrate.
> Microkernel construction, at this point, isn't really where the new value
> lies. Once he had a set of ideas he was ready to pursue, it made sense to
> fill in the blanks.
>
> My one concern with Viengoos -- and I have expressed this to Neal many times
> -- is that in the pursuit of better resource arbitrage Neal has given up
> resource isolation, and there are fairly important (and unfortunate)
> security consequences for that. It is possible that these can be addressed,
> and it is fair to experiment on one thing at a time, but it needs to be
> clearly understood that Viengoos is an experimental kernel, and that it is
> *not* suitable in its current form for production use.
>

The main difference as I understand it is that Coyotos enforces 'hard'
resource allocation - the resource either is allocated to the process
or it is not.

In Viengoos surplus resources that are not in use by any process can
be used by processes that are interested. This leads to better
utilization of resources but somewhat loosens security. Processes can
see how the system is starved for resources and artificially modulate
resource demand to create a communication channel.

This is not something that is completely addressed in Coyotos either -
there still can be observable increase in latency when the system is
under load. Coyotos aims to get nearer to the absolute isolation
ideal, though.

If there is practical security difference between the Coyotos model
and Viengoos model is yet to be proven. The same communication channel
exists in both and it's a matter of estimating and measuring the
bandwidth.

When this kind of security is a concern the Viengoos model can be
amended by introducing 'hard' domains which cannot access surplus
resources outside of the domain.

However, good resource utilization is often of more concern on desktop
systems and even some time-share systems and Viengoos addresses this
need better than Coyotos. An application like keystore should be
trusted for other reasons so in a working system it will not use this
communication channel to transfer your keys. If you are interested in
absolute secrecy of all your data you should take additional measures
in both Viengoos and Coyotos.

Thanks

Michal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]