No. The fact that the kernels on the N processors can securely (?) talk with each other [this is the biggest problem, IMO] means "capabilities" can be passed from taskXy (task X on cpu y) to taskAb (my previous point).
The kernel can likewise participate in the regular IPC (in this case, RPC!) between those tasks. I.e., the "communication channel" associated with a particular object's server on cpu N can be accessed *via* the kernel on cpu M.
I.e., the kernels have to conspire to implement a "virtual kernel" that spans the many processors.
This puts a lot of work into the kernel. But, since it is just virtualizing a communication channel(s), the kernel can pass untyped data without having to understand what the object/service in question might be.
Again, this sucks (using the criteria I mentioned before) because "someone else" pays for the work done on behalf of a task instead of the task itself. E.g., a malicious task (or a misbehaving task!) wastes resources that "morally" belong to all of the tasks who are "playing by the rules".
Argh! Sorry, I've been discussing capabilities in the general sense. I don't use anything this complex in, for example, the audio clients; they are tiny and "not complex" (i.e., "fit in one human brain")
I name every system object -- services, etc. (I posted a question about this some time ago).
In a multiprocessor, this means you need some way of globally naming things. This can get expensive if you have lots of objects being created/deleted. And, some objects really only need local awareness (e.g., IPC channels that never leave the node). So, there is value to adding a local name service *agent* that can maintain a local namespace *and* interface to the global namespace as needed (on behalf of local clients).
86 the proxies. As long as the client(s) on B can locate the service (on A?), the kernel can move the required data between them.A capability can have lots of "names" (handles). E.g., task1A might be the server for an object. It's handle for a capability might be 0x1234. When it passes that capability to task2A, it might be known as 0x5432 to task2A. Meanwhile, kernelA might know it as 0xA5A5.
When the capability is passed to task6B, the kernelB reference might be known as 0xB7B7 while task6B knows it as 0x8642.
Think of how two processes reference a single file in a filesystem. Each has a separate handle to it yet it is still the same "physical" (inasmuch as any file is "physical") file.
If that file is served via NFS, then the NFS server has a handle to it -- which differs from either of the other two processes, above. And, when the NFS *client* (other host) accesses the file, it has still another handle!
Dealing with capabilities is one place where I have to work really hard NOT to think in terms of actual "values" but, rather, think of them in an abstract sense: "This lets me turn on the motor", "This lets me erase the hard disk", etc.
The (big) win with that approach is the capabilities can be "examined" without the active involvement of the server. I.e., the server can publish (to something in the kernel?) the "right" capabiliti(es) for a particular RPC/IPC and the grunt work of decrypting and checking against the "right" template can be offloaded to some common library function.
E.g., you can embed a bitmap in the capability where each bit corresponds with a particular action and let the library do the test for you.
It would be nice (see above) if the "validation" could be removed from the "managing server". Think about it... it's a mundane task that *should* be offloadable (but I can't see how to do it in "my" approach :-/ )
Agreed! There's no free lunch. I try to fast-path operations
*within* a session to hide the costs of processing the capabilities. But, this makes the connection "fatter".For the audio clients, I have to implement mechanisms to prevent rogue clients/servers from corrupting the data passed to these devices. But, can't rely on simple connection oriented protocols (because they can be spoofed/intercepted).
So, I'll have to do something like implementing an encrypted tunnel. Or, maybe just "sign" each packet and have the devices fail-secure if they detect attempts at passing corrupted data to them.
[this is a crappy solution because it means any attack denies service. OTOH, with the resources available in these boxes, I don't have many options... :< How do you protect the devices in your PC on the memory bus from a rogue bus master??]Yes. That was my unfortunate conclusion :>
Yes. You can come up with solutions. My point was that these are realistic problems that can turn up and have to be addressed. If you just take a naive approach ("Let's make a 'configurator' that we can sell to customers so *they* can configure their devices prior to deployment") you can overlook bigger usage problems.
E.g., many years ago, I worked on an (physical) access control system. The system was *really* clever! It's simplicity was pure elegance!
But, the implementation of the "key maker" had serious flaws. Within minutes of my first exposure to the system, I demonstrated how a (malicious) user could make an infinite number of "grand master keys" completely undetected -- simply by unplugging one cable in the process! Ooops!
"But you're not supposed to *do* that!"
"Then why did your system *let* me??" (and, why didn't it notice that I had done this?!)
I haven't tried protecting against rogue *clients*. I.e., if you want to buy some of these boxes and attach them to the system... I'm assuming trust flows one way (i.e., I don't "trust" anything coming from the devices).
I'm more concerned with, for example, the devices being wired to the field and some rogue application runs on them and does bad things (runs a motorized mechanism "into the stops"; sets the temperature of a tempering oven too high/low; discards every product coming off the assembly line; etc.)
*If* you can get a secret into each legitimate device, then they can routinely communicate with "something" -- as part of the normal application.With the self-configure scheme I outlined, if you set up that KNOWN SECURE connection in The Back Office *and* only served up an image that stored the secret in the devices' persistent store from that connection (e.g., a different network I/F), then you could be sure only *your* devices got *your* secret.
So, if a rogue device was deployed on the "public" interface for the server, the image that gets served up by the *legitimate* server would not include the code fragment that sets the secret. As such, the device would never be able to *run*.
Correct. I am convinced there is no way to avoid some mechanism to put the secret into the device -- at least initially.
Toilets come in a close second! :>
Ditto for toilets! ;-)