Re: Security models

[olafBuddenhagen]

Hi,

On Fri, Dec 12, 2008 at 07:30:53PM +0100, Arne Babenhauserheide wrote:
> Am Samstag 06 Dezember 2008 22:17:12 schrieb olafBuddenhagen@gmx.net:

> > So you have offlist discussions, have you? I feel left out ;-)
> 
> The discussion stumbled offline since Michal accidently only answered
> to me and I wasn't sure if he just wanted to avoid spamming the list
> with DRM discussions... 

Well, your original remark sounded as if you had some off-list
discussion with Neal, in which case I would indeed feel sorry not to
participate...

As for the discussion with Michal, I actually tend to think that it
would be better if it had remained off-list -- as I said originally, all
of these things have been discussed on the l4-hurd list in the past, and
I don't see much benefit to the general public in reiterating them here.

> What I mean is: What happens if the request the user sends to the
> system process needs more memory than what's expected? 
> 
> Does the system process just say "this is the maximum buffer length,
> don't send me more", or is tehre some way it can increase the memory
> it has access to? 

Well, depends on what exactly you mean by "memory". Physical memory is
scarce, but usually processes do not really need much of it to remain
operational -- they will only slow down if they get too little...

Virtual memory on the other hand is relatively cheap. The situation that
a process fails because it doesn't get enough of it is rather uncommon
really.

For virtual memory backed by named storage (mmapped files), the limit is
only in the amount of filesystem usage the process is allowed -- usually
users won't restrict that too strongly, so the limit is not likely to be
hit, unless the process is malfunctioning, or the user exceeds his
global disk quota.

I'm not sure what the plan is for anonymous memory (backed by swap).

Also note that the plan is for server processes generally to avoid
dynamic allocation on behalf of clients. Requests should be served in
constant memory amount, and/or client-provided memory -- at least that's
my understanding.

> (by the way: having a user process which manages a non-restricted
> buffer should give almost the same advantages as giving memory
> directly to the server, but without the drawbacks. And it should be
> painless, since you'll most likely access the system process through a
> library anyway, and the library can handle the buffering)

No idea what you are talking about...

> > 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.
> 
> How do the system processes fit into the picture?

System processes are really just processes run by other users -- either
by root, or by some other system user created specifically for the
purpose of running the respective service.

> It depends on people understanding "remote-attestation", but in this
> list that should be a given

Actually, I don't think that all people on this list know about remote
attestation... OTOH, it was really only a reply to Michal -- I don't
think there are many others reading this (sub)thread anymore :-)

-antrik-