RE: On PATH_MAX

[Christopher Nelson]

> At Thu, 3 Nov 2005 12:38:19 -0700,
> "Christopher Nelson" <address@hidden> wrote:
> > problem.  I don't see how their relationship really 
> matters.  Somehow 
> > A
> 
> I already tried to illustrate why.  For example, B might be a 
> "child-thread" of A, and thus has complete trust.  In this 
> case, B can do whatever A wants, and will be likely to 
> programmed this way.
> 
> Without assuming _anything_ about their relationship, the two 
> threads _can_ _not_ communicate.

I was assuming only that they had a communication relationship.  It's
not important what the specifics of that relationship are.
 
> > has a capability that lets it talk to B.  Neither thread has any 
> > authority *over* each other, but B provides a service.  The problem
> 
> B provides a service under which conditions?  You have to specify.

Threads A and B exist on the same machine, but in separate protection
domains.  It would be equivalent to say that they exist in different
address spaces on most modern CPUs.  Given this condition, they can only
communicate via either copying memory contents or else mapping memory
contents.

> > exists even if B provides no service to any other thread, because 
> > memory and processor space are shared resources.
> 
> In EROS, B has a space bank and a scheduler reserve.  This 
> gives it access to a certain amount of memory and cpu time.  
> What is the problem?
> 
> In other systems, it is similar.

The problem is that both threads must have mappable address space of
equivalent extent.  The point was to illustrate that it is possible to
perform denial of resource if you allow arbitrary-length string transfer
even when the memory is allocated from someone else's address space
originally.

I don't see how simply providing space banks prevents this sort of
denial of resource.  Perhaps you can explain:

A) how allocating memory out of a space bank from thread (or process) A
doesn't utilize address space in thread (or process) B.
B) how a thread can straddle two address spaces simultaneously and yet
maintain confinement.


> You have two options.  You can safe the internal state and 
> resume the operation at the right point after the restart.  
> Or you can restart the whole IPC.  The latter choice seems to 
> be simpler to me from the kernel perspective.  In this case, 
> the operation will never complete.
> 
> Ok, I think I have just shown that the kernel doesn't need to 
> care if it is carefully implemented.  For string items at 
> least.  But, and this is a big but, now you don't get any 
> guarantee from the kernel anymore that _any_ such IPC will 
> _ever_ complete.  Is such an implementation useful?  I have doubts. :)

This is what I was asking, and I agree.  You can either save the state
in the kernel (annoying and difficult with persistence), or have a
mechanism whereby the map or copy isn't committed until it finishes
entirely.  Perhaps a copy-on-write of the mapping tables of the receiver
so that when the entire IPC operation finishes the change can be made
atomically.  If a crash occurs before the tables are finished, it
doesn't affect anything because the checkpointed, in-use tables were
never touched.  You can make a guarantee that it will either finish
completely or not finish at all.  As far as guaranteeing that something
will ever finish, if someone keeps rebooting the computer you're never
gonna get any work done. :-D

-={C}=-