2009/11/4 William Leslie <[email protected]>: > 2009/11/4 Michal Suchanek <[email protected]>: >> 2009/10/28 Jonathan S. Shapiro <[email protected]>: >>> 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
