[cap-talk] Cap OS question

David-Sarah Hopwood david-sarah at jacaranda.org
Sun Sep 6 18:01:30 PDT 2009


Sandro Magi wrote:
> Mark Miller wrote:
>> From looking at your slides again, I wonder if AppDomain is actually
>> more like J-Kernel[1] than Joe-E. Do you have a sense of how AppDomain
>> compares to J-Kernel?
> 
> Yes, the confinement is process based. AppDomains are a standard process
> abstraction provided by the .NET CLR. The slides describe a trusted
> kernel that runs all app code in AppDomains whose permissions are all
> revoked via the CLR's Code Access Security (CAS -- declarative access
> control via stack-inspection); these include permissions to open files,
> sockets, perform reflection, etc. The kernel provides a tamed API that
> may call out to a Powerbox to extract the necessary authority.
> 
> Unfortunately, CAS incurs quite a bit of overhead due to all the runtime
> checking, so it would be far less efficient than bytecode verification.

I don't understand why the overhead due to CAS checks is any greater
in this kind of design. When the application uses only the tamed API,
it is not directly making any requests that would cause a CAS check.
(The CAS overhead is only incurred on a check, not per stack frame.)
The taming library makes requests that need not involve CAS checks
because it is running in another AppDomain that could be given FullTrust
(or even if it is not given FullTrust, it would have the same permissions
that a domain in a system relying on bytecode verification would have, so
there is no extra overhead).

There might be extra overhead due to the IPC between AppDomains; I don't
know how significant that would be.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



More information about the cap-talk mailing list