Re: [ANNOUNCE] Introducing Codezero

[Bahadir Balban]

Hi,

Sorry for the delayed reply, I have been doing some coding.

Jonathan Shapiro wrote:
>  
> What Sam is saying here -- but didn't actually state -- is that your 
> definition of "object based" doesn't agree with the rest of the field. 
> There is nothing wrong with the concept you are describing, but you 
> should find a more appropriate name for it.
>  

OK, by object-based I mean a CORBA-like distributed computing
architecture where object instances are defined on the server side, and
clients refer to those object instances by references to them (sometimes
by using their memory address as a key). In this model, the client uses
an interface definition language in order to generate boilerplated code
to access or refer to methods available on the remote object.

The key points here are that;

* Programing is done in object-oriented fashion.
* Objects are created, and accessed by *automated* methods such as an OO 
programming language, IDL compilers, stub generation etc.

From what I understand, in the Hurd project a similar model is further
modified where a capability is associated with every object such
that, the capability reference is the only gateway to access an object.
With capabilities, every method of a given object is subject to security 
checking.

Nevertheless it is a nice, clean model for fine-grain security. I can
see the point in it.

My idea in a nutshell is to remove the initially described methods of
creating, managing, referring to objects, (as I find them to complicate
design) and define ad-hoc, or loosely defined resources, but continue to
protect them by capabilities. These resources can be thought of as
objects, but only conceptually, rather than being created by automated
tools such as an OO programming language or IDL compiler.

> A capability is a *protected* structure that designates (names) a 
> resource and specifies a signature of operations (methods) on that 
> resource that may be invoked through that capability. It is common for 
> the storage of that method signature to be implemented by permission 
> bits, and in the early literature capabilities were characterized as 
> "designation plus permissions". The definition I'm giving is more 
> consistent with modern semantic theory.
>  

This is *exactly* what I understood from capabilities. I have in fact
defined a kernel data structure to protect kernel resources this way:

struct capability {
        struct link list;

        /* Capability identifiers */
        l4id_t capid;           /* Unique capability ID */
        l4id_t resid;           /* Targeted resource ID */
        l4id_t owner;           /* Capability owner ID */
        unsigned int type;      /* Capability and target resource type */

        /* Capability limits/permissions */
        u32 access;             /* Permitted operations */

        /* Limits on the resource */
        unsigned long start;    /* Resource start value */
        unsigned long end;      /* Resource end value */
        unsigned long size;     /* Resource size */
};

Now, this structure could be easily generalized by adding a pointer
reference to another structure (i.e. an object), but in its current form
it was sufficient to describe every kernel resource.

I won't go into detail, but some of the resources (i.e. conceptual
objects) protected are: system calls (ipc, thread control, etc),
threads, memory regions, capabilities, and quantitative resources such
as cpu time, # of threads, # of address spaces etc. You may take a look
at the list of resources protected, and list of capability
operations here:

Capability types:
http://www.b-labs.co.uk/git/?p=codezero.git;a=blob;f=include/l4/generic/cap-types.h;h=944057cea2dec72eb8ff408d16ccce5078379729;hb=devel

also, the capability struct:
http://www.b-labs.co.uk/git/?p=codezero.git;a=blob;f=include/l4/generic/capability.h;h=2cac2da0b57a98cb2111a83731d3f6af55ea4448;hb=devel

and a use-case:
http://www.b-labs.co.uk/git/?p=codezero.git;a=blob;f=src/generic/container.c;h=0c8a86a349bbee1d95f3ef7072555e9acb0638c8;hb=devel

> But the protected part is important. In order to be a capability it must 
> be non-forgeable. In order to achieve some of the behavioral properties 
> that we often associate with capability systems, it must not merely be 
> encrypted bits. The reason is that we want to be able to constrain the 
> propagation of capabilities, and if they are just bits then we really 
> can't do that.
>  
>  
> shap

Since the above capability mechanism is incorporated in the kernel, (and
we implicitly *trust* the kernel here) we have the protection as you
suggested.

But back to my conclusion with objects, in the above example model,
instead of using automated methods of creating, referring, managing
objects, the number of resources protected are reduced to a minimum set.
Also, the set of operations allowed on them are reduced to a minimum
set. The protection is still there, but the resources are defined with
an optimized, hand-crafted engineering method instead of using automated
tools, thus reducing the complexity.


Thanks,

--
Bahadir Balban