Split Capabilities: Making Capabilities Scale

[Norman Hardy]

At 11:36 +0100 00/07/25, Ben Laurie wrote:
>"Karp, Alan" wrote:
>>
>> Ahh, so that's the difference.  I was assuming that, as a holder of the
>> decrement capability, I see an object that can only be decremented.  In this
>> view, any increment is a side effect outside the object model.  You are
>> saying that a holder of any of the foreseen facets is automatically aware of
>> all the other foreseen facets, or at least those with visible effects.
>> Thus, any action appearing in a foreseen facet is within the object model.
>>
>> This point raises an interesting question.  Knowing that an operation is
>> possible makes a certain class of attacks possible.  Hence, we want to
>> institute a policy of least information.
>
>Umm ... security that relies on people not knowing things is generally
>bad - your threat model should generally assume that the attacker is in
>full possession of the facts about the system (after all, he wrote it,
>didn't he?).
>

There is another general reason to hide information that is "not needed".
It is not a security property but rather an effort to provide a
stable application environment.
The x86 architecture allows an unprivileged program to read the register
which is set by privileged code and informs the hardware where the
interrupt vector is. The complexity of the VMware software was
multiplied many times by many such mis-features. Most machine
architects instinctively hide such information and virtual machines
for such architectures are vastly easier and more efficient.
It seems that the IA64 does not have this problem but there
are nearly 1000 pages of definition to read.

The Keykos KEYBITS key reveals capability bits to its holder. It also
returns a version number of the format in case it is necessary to
reformat all of the keys asynchronously with running applications
that might use such information. The only critical program that holds
KEYBITS was tested to see if it could survive a discontinuity in
format number.
Norman Hardy  <http://www.mediacity.com/~norm>