Re: Broken dream of mine :(

[Michal Suchanek]

2009/11/4 William Leslie <address@hidden>:
> 2009/11/4 Michal Suchanek <address@hidden>:
>> 2009/10/28 Jonathan S. Shapiro <address@hidden>:
>>> 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.
>
> I would probably say that "the resource is allocated or not".
> Ownership is not addressed by the Coyotos model, quite simply whoever
> has the capability to it can use the resource. The question of who
> pays is not part of the core.
>
> When you allocate a resource, you do so by invoking some authority.
> This authority does not, at least in the case of the core servers,
> specify how the resource is to be divided or shared: that
> functionality must be implemented by the servers that implement that
> user resource.
>
> Capabilities that specify actual hardware allocation, the kind that
> are dealt with by Coyotos, should probably be proxied by the operating
> system and not handed out directly. The operating system should do as
> Viengoos does: turn invocations of capabilities to relative time
> slices into concrete ones.

Indeed, whoever has the capability can use an object. This should be
same for Coyotos and Viengoos.

However, the logic we build on top of capabilities usually designates
a consumer of the resource and manager(s) of the resource. The
consumer uses the resource and the manager may have technically access
to the resource but should only use it to give out capability to the
consumer and revoke it when required. In Coyotos the opaque memory
pattern allows for managers that do not have access to the resources
they give out to the consumers.

The manager has access to a finite amount of resources that it can
divide between consumers and each consumer has a set quota of
resources it can obtain. The sum of quotas must be equal or lower than
the amount of resources available (or the shares can be relative).

In Coyotos the manager is simple and robust - it just ensures that the
sum of quotas is not higher than the amount of resources available and
that no consumer gets more resources than its quota.

Where Viengoos tries to improve over Coyotos is in this userspace
manager - it tries to allow dividing resources that are currently not
allocated or communicating which pages are more valuable for an
application.

I think this different resource manager should be portable to Coyotos,
it just happens to be developed on Viengoos.

>
>> 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.
>
> Coyotos privides page pinning and intended to provide (only!) hard
> time slices. Between these two, you can positively assert that some
> exact set of resources are provided. You even have isolated TLB-fill
> times. The only covert channel that I can see is cache utilisation (I
> could say "on architectures that don't support cache locking", but I
> don't think there were plans to reify this where available either).
>

This would hold only if you allowed starting no more processes than
fits into the physical memory. As far as I understand the (yet to be
implemented) Coyotos execution model the on-disk state is the
canonical system state and processes that need to change their state
are temporarily cached in RAM. Depending on the amount of changes that
are made to process data there may be more time spent loading and
saving the data pages which is observable. This is not part of the
kernel, though. The kernel only ever cares about the physical
resources which are easily traceable but Coyotos is supposed to be a
complete system, not a kernel.

Thanks

Michal