[E-Lang] Performance and complete mediation

[Karp, Alan]

> -----Original Message-----
> From: David Wagner [mailto:daw@cs.berkeley.edu]
> Sent: Monday, August 06, 2001 11:52 AM
> To: e-lang@mail.eros-os.org
> Subject: [E-Lang] Performance and complete mediation
> 
> 
> Alan Karp recently wrote the following about mediated requests
> between processes in e-speak Beta 1.0:
> > After a fair amount of tuning effort, our round trip trivial
> > request time was 1 ms on a 300 MHz Pentium.
> 
> Maybe I misunderstood something, but it seems that the stack 
> introspection
> paper argued that this is orders of magnitude larger than one 
> would like.
> Am I missing something?

Nope.  You didn't miss anything, but don't attribute my numbers to other
capability systems.  EROS, for example, will be orders of magnitude faster.
Also, those times were measured on a 300 MHz machine; on a modern 1 GHz
machine the performance would be proportionally better. 

A value of 300,000 machine cycles (1 ms/300 MHz) is too large to compete
with operating system calls.  However, as I noted, about 80% of that time
was context switches.  You clearly need to be part of the OS to do anything
about that.  Since we were not, our design was for protection of e-services
in a distributed environment, rather than OS service calls on single
machine.  Our feeling was that once you touched the network, you were
talking ms latencies anyway.  Nevertheless, with some tuning, the core
handled several hundred to a thousand requests per second.

We did measure the critical path through the code.  It included a few hash
table lookups and some string comparisons.  The biggest part of the time was
spent in copying the messages from one buffer to another.  Had the other
parts of the overhead been smaller, we could have optimized that piece.
Could we have gotten down to 1,000 cycles ( 1 microsec/1 GHz)?  Unlikely,
but a few times that would have been doable, I think.

> 
> In Wallach et. al's paper on stack introspection, they argue that
> an important barrier to fine-grained protection domains is the cost
> of crossing protection domains.  They show some simple applications
> that make about 30,000 boundary crossings per second, and argue that
> cross-domain calls need to run in microseconds to take 
> advantage of the
> natural structure of the system (in terms of least privilege).

Those number are not far off from the ones we used (scaled by Moore's law,
of course) when we had visions of being in the OS kernel.  At that time, we
thought we could get close to them.  However, once we decided that
supporting NT was important, we gave up that particular ghost.

> 
> They argued that if cross-domain calls take longer than this, 
> programmers
> would be dissuaded from taking advantage of the natural 
> structure of code
> and would structure the application in unnaturally 
> coarse-grained domains,
> with attendant loss in security.  (Since the isolation properties of a
> safe language are partially intended to prevent failures from crossing
> protection domains, aggregating domains in this way violates 
> the principle
> of least privilege and thereby increases the risks.)

We made a clear distinction between objects in an address space and those in
different address spaces; each address space corresponded to a protection
domain.  Not being part of the OS meant that we couldn't prevent a process
from doing anything it wanted within its address space, something a
capability secure OS, like EROS, can do.  Our focus was on allowing the
client owning a resource to control access to it from other clients, not
from itself.

> 
> If you buy into this argument, and if cross-domain calls take 1 ms on
> your platform, then it would appear that programmers will be 
> artificially
> steered towards unnecessarily risky architectures for the code they
> write.  This line of reasoning suggests that performance has important
> implications on security, and moreover that 1 ms might not be 
> fast enough.

Actually, I think we met our stated goals quite nicely.  We just didn't meet
yours. :)  

The point is that we could protect access to resources.  Exactly what
resources we could effectively protect depended on the latency.  Once we
made the decision to stay out of the kernel, there was no point trying to
push the latency down far enough to protect memory segments.  Our
measurements showed that applications typically made no more than a couple
of hundred requests per second to the kind of resources we could protect,
and that we were able to support.

> 
> That's if you buy into their argument.  If you're not 
> convinced by this
> argument, then all bets are off, of course.
> 
> Did I go wrong somewhere?

Nope.  But your arguments apply only to e-speak, not capability systems in
general, especially not to capability secure OSes.

> _______________________________________________
> e-lang mailing list
> e-lang@mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
> 

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/