Why Cap Platforms; short version
Today you will hear many thrusts to facilitate mutually suspicious programs cooperating over comm links.
I address here mutually suspicious programs cooperating inside one system where messages cross protection boundaries in a few hundred clock cycles — less than a microsecond.
Three or four orders of magnitude enable classes of application and it is also critical for the security of distributed applications.
This technology originated when computers were expensive, shared, and operated by some widely trusted organization.
Today the same technology promises a platform where critical functions can operate while relying on a megabyte instead of gigabytes of correct, or at least benign software.
A few orders of magnitude help here too.
With the proposed technology there may be gigabytes of useful code on your personal device but your critical functions rely on less than a megabyte.
I think there are no such solutions today.
First get the small parts right
Capabilities support a variety of patterns that solve security problems.
Programming languages, since at least Algol 60, have limited access to variables so that one could confidently reason about a small part of a big program while considering only the source of the small part.
Capability notions can guide OS design to extend such benefits to the platform.
Mutually Suspicious Routines Calling each other
Conventional platforms generally lack features to load programs from mutually suspicious sources into one address space so that they can communicate with the performance of modern compiled code, and also rely on the protection inherent in some modern language designs.
Keykos lacks this too.
This could be provided at the language level by providing a REPL (Read Evaluate Print Loop) version with multiple REPLs each attached to their own terminal.
The programs thus introduced would live in the same execution space, able to call each other, passing references, via a programmed switch board via which different REPLs could make initial contact.
I have worked out such details for Scheme.
At that point mutually suspicious programs can interact with subroutine latency instead of Internet latency.
Problems remain in this story.
We must consider space and time lest one REPL consume all.
Few languages support this.
Instead most rely on some platform function.
This is a DoS attack when someone you do not trust decides to loop or exhaust storage.
This could be added to a language, at considerable complexity cost.
Further we cannot expect all programs on a personal computer (or phone) to be written in one language.
Keykos developers decided to do all of this at the machine level relying on classic virtual memory logic and privileged mode logic originating in hardware of the 60’s.
There are a few other systems like Keykos in these regards; seL4 is a very interesting recent system.
I will speak of Keykos here.
In such a system you allow programs written in various languages each to directly invoke system level capabilities.
System integrity does not rely on language safety, but, of course, it still relies on correct operation of any programs on which the system relies.
The plan outlined here assumes classic hardware protection, which modern hardware still claims to deliver.
Here is the insight that conventional CPU’s support (segregated) capability patterns.
It also accommodates applications and utilities from other platforms, adapted to capability conventions by ad-hoc adaptors.
The result is a cosmopolitan neighborhood of programs upon which fine-grained capability authority is imposed.
Much of the first three layers has been implemented and the source is available for hardware that is, alas, out of date.
The fifth layer has not had serious development or even design except to support system developers with a shell like interface.
Don’t Forget the User
Commercial success among casual users requires addressing the design of layer 5 which helps the user, who is smart but not a computer expert, understand the security implications of his actions.
Apple is sure that they can hide all such issues from the user.
I am not.
I suspect there is a gamut of such UI’s, perhaps one program sensitive to the security sophistication of the user.
There are power plants to run, cars to drive and quite a few more places where levels 1, 2.1, 2.3, 4 and a small taste of 3 will deliver a small secure platform.
They might serve as an entré into larger markets.
Most of the software you rely on need not be suspicious to preserve your security.
A matrix inversion object need not guard against malformed matrices to protect you against enemies.
Even if your enemy uses objects obeying the same code, they may corrupt their own inverter, but that inverter has no access to your matrices.
You do rely on some software to be suspicious of invocations because the objects that it defines must be shared with your enemies.
Buying space presumes that your enemy cannot see that space.
Conventional hardware starting in the mid 60’s delivered function that could support many patterns of organizing software so that you could minimize unnecessary software dependencies while supporting fairly efficient interactions.
Conventional kernels starting in the mid 60’s did not deliver that function.
Capability kernels on conventional hardware can and many do deliver that function.