Hi, On Thu, Dec 04, 2008 at 07:28:23PM +0100, Arne Babenhauserheide wrote: > Am Mittwoch 03 Dezember 2008 13:57:12 schrieb olafbuddenha...@gmx.net:
> > When a process needs the service of another process which deals with > > resources it has no access to itself -- say a powerbox -- it doesn't > > launch that process itself. Instead, it invokes the service from a > > process launched by another party. This way it has no access to the > > resources of that other process -- but the user who launched that > > other process does have control over it. > > To a question we had offlist So you have offlist discussions, have you? I feel left out ;-) > Can that service request more memory when it runs out of memory (which > it can give new processes), and can it offer proper resource > management, so users can't harm each others performance? Not sure what you mean exactly... As the service in this case has information that the client is not supposed to see directly, it can't use client-provided resources. Instead, it has to get its own resources from its own parent. (Thats a major difference from the Coyotos model.) In some cases, the server and the client process will be both immediate children of the same parent, and the parent directly divides the available resources between them. In other cases, the relationship might be more complicated. Some services might even be created by the user session directly. Users should never be able to harm each other's performace in this model. All processes created by a user are descendands of the user session; the total resources available to the user will be subdivided among them, in a hierarchical manner. > > Indeed, this is the real threat: We can't fool the server. If remote > > attestation becomes commonplace, Disney will be able to deny access > > by our non-treacherous system alltogether. > > > > That's why we need to fight the TPM stuff teeth an claw. > > I couldn't have stated it better. Really? That's surprising -- usually you are expressing the things I mean to say much better than I could do myself :-) -antrik-
