On Fri, Jul 4, 2014 at 8:10 PM, Matt Oliveri <[email protected]> wrote:
> The endpoint identifier is the OID field in an endpoint > capability? So the implementing process gets to see that, but not the > invoker, unless they are authorized to use CapBits on it? No. Short of using CapBits, which is wielded by exactly one program, nobody ever sees the OID. The endpoint ID is set by the holder of the endpoint capability. Having set the ID, you then fabricate an Entry capability, which is a different capability type that also points to the endpoint object: http://coyotos.org/docs/ukernel/spec.html#coyotos.Endpoint The only program that holds capbits is the program that implements the "capability set" object. It uses that to build an index as data of the capabilities that it is holding. Holding capbits violates the notion that capabilities should be opaque. The capability set object holds it by virtue of being in the primordial system image. Once the system is up and running, I don't think capbits is actually available to even be *given* to anything else. It looks > like Coyotos itself doesn't need to care what constitutes an object > implemented by an application. It just needs to faithfully report the > (uninterpreted) protected payload and OID to the appropriate process. > That is exactly correct. Coyotos acts as an atomic message transport to the implementing process. There *is* a little bit of crossover because capabilities to kernel-implemented objects are invoked in the same was a capabilities to user-implemented objects. In UNIX, the operation (system call #) is decoded first and then the arguments are decoded. In EROS and Coyotos, all argument payloads are uniform. The arguments are validated first and the receiver of the message (kernel or process) is identified late. > > On Fri, Jul 4, 2014 at 4:45 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > In KeyKOS/EROS, the "discrim" capability (which implements EQ) was > closely > > held. In Coyotos we were more liberal, and we haven't gotten into trouble > > yet. But in general we leave it up to the object developer to decide > whether > > they want one capability on their "thing" to acknowledge whether it > > designates the same "thing" as a second capability. > > The point being that applications usually wouldn't use Discrim? Correct. Offhand, I think the only application that uses Discrim is the Constructor object, which is one of the core security-establishing objects in the system. > In that case how would Coyotos applications usually implement object > identity comparison? Say, to determine if images linked from two parts > of a document are the same? As the receiver on an endpoint, you know what endpoint was invoked and with which protected payload. If those two things match, then the invoked capabilities were the same. So there's a trick where the caller invokes one cap passing the other, and then the serving object invokes the second to extract the endpoint ID and payload of that. But now that you mention it there's a missing link in the protocols. Hmm. I'm thinking here that Discrim is widely available. It's been a while since I've looked. > There is a "capbits" capability that is VERY closely held. There's > actually > > only one object that wields it in production: > > > > http://coyotos.org/docs/ukernel/spec.html#coyotos.CapBits > > Does Discrim.compare agree with bit comparison of the results of > CapBits.get on the two capabilities? > Yes, modulo the fact that some bits in the capability representation revealed by discrim are details of implementation. > > The operation that inspires "guarded open" is the identifyEntryWithBrand > > operation on Coyotos processes: > > > > http://coyotos.org/docs/ukernel/spec.html#coyotos.Process > > So the brand is the guard, and it might provide authority because it > reveals the endpoint's protected payload and ID? > Yes and no. The brand is the guard, but it doesn't "provide" authority, except in the sense that holding it is necessary to de-encapsulate the object. Yes, the identify operation (which, note, is performed on the *process*) can be used to identify whether an endpoint points to that process. I'm not sure why you showed me this. It seems like Coyotos doesn't > have much to say about object identity for application-specific > objects. Right. And that's the point. You can build very rich systems without having much to say about object identity, and without letting applications in question even ask the *question* about object identity. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
