[cap-talk] Concening entry "ambient authority" in Wikipedia

[Marcus Brinkmann]

Charles Landau wrote:
> Marcus Brinkmann wrote:
>> A close analysis will reveal that the situation is not so simple.  For
>> example, the wikipedia page "Object-capability_model" cites Java global
>> variables as a different way to access resources.  But in a capability system
>> memory load/store instructions are *modeled* as messages to memory pages that
>> are part of the processes page table, where the relevant capabilities are
>> named implicitely through the architectures process model.  And in fact, the
>> hardware's page table is just an optimized implementation of those
>> capabilities
> 
> Are you saying that one can deny a Java program access to global 
> variables by constructing an address space that lack the relevant memory 
> page capabilities? I think not, otherwise they wouldn't be *global* 
> variables.

I think you mean to say "...deny a Java object..." here.  No, that's not what
I am saying.  I am only saying that global variable access can be modeled
within an ocap system quite naturally.  This again would be an undeniable,
undroppable implicit capability shared by all objects in the Java VM.

So, it seems most people here (not me) agree that capabilities must be
deniable or droppable (we don't have formal definitions of those terms, but
they have some intuitive meaning I hope).  That is a requirement that could be
added to the ocap definition, but it's not a requirement that is currently
contained in it as far as I can see (for example on the wikipedia page).

> To quote the Wikipedia page:
> 
> "An address can be obtained by: 1. creation: creating a new object ... 
> 2. receiving a message ... *all* computation is performed following the 
> above rules."
> 
> If there are memory pages that aren't optional, they are received by 
> some means other than the above.

I don't see how that follows.  In my mind, these undeniable capabilities are
received by creation.  To stick with examples, it is not the Java object that
creates the global variable memory pages, but the higher ranking Java VM.
Similarly, in Unix the kernel (or the process creator == exec object) creates
(implicit, unnamed) capabilities to access the file system (among others).

Here is the problem: Taking your quote literally, ocap systems don't exist in
the real world, because there are no cpus that work by creating objects and
sending messages around.  You can write down a model where numbers are objects
1, 2, 3... with interfaces "add", "subtract", etc.  If the model were to
capture a significant portion of existing CPU architectures accurately, a lot
of aspects would appear naturally as well, which the ocap model as you
understand it is trying to avoid.  In particular, relevant to this discussion,
there would be an undeniable set of capabilities, such as "numbers", that are
given to every process.  This means that it is probably not a good idea to
include "deniability" or "droppability" into the definition of an ocap system,
as to not preclude efficient implementations.

I am not saying that there is no distinction to be made here.  In particular,
the difference between numbers and (persistent) files is that operations on
numbers are free of side effects, and thus "safer".  But that has nothing to
do with the ocap model anymore.

All systems will, for performance reasons already, optimize some capability
accesses in hardware or software, to a varying extent, depending on what the
designers of these systems consider to be safe.  Most will agree on side
effect free actions like number calculations, private anonymous memory and
global read-only memory.  Many will agree on wall time.  The designers of Java
chose to include global variables.  The designers of Mach choose to give every
process a capability to itself (mach_proc_self). The designers of Unix chose
to include the file system, among other things.  But I don't see how the term
ocap-model tells us where this line is or should be drawn.  Other
requirements, such as "being free of side effects" or "not leaking information
to outside processes", OTOH, can tell us where to draw the line.

Thanks,
Marcus