Representation of unions on capability machines

[Craig Jackson drilex1]

In article <29561 at news.Think.COM> barmar at think.UUCP (Barry Margolin) writes:
>Jeff Rosenfeld's (jdr+ at andrew.cmi.edu) posting in the "effect of
>free()" chain got me to thinking about how unions containing pointers
>and non-pointers would be implemented on a particular class of
>machine.  The class of machines I'm wondering about are capability
>machines.  On many of these machines, pointers are actually
>capabilities; the access rights that a process has to some data is
>encoded in the capability word.  A consequence of this is that
>capabilities may only be created by secure code, although they
>generally can be copied by user code; if user-mode code could create a
>capability, it could fill in whatever address and access rights it
>wanted and thus bypass the system security mechanism.  ...

[More information about capability machines.]

>Without getting into debates over the reasonability of capability
>architectures, I'd like to ask what the appropriate way to implement a
>union like
>
>union pi {
>    char *ptr;
>    unsigned long num;
>} x;
>
>is on a machine that has separate data and capability pages.  Does C
>require that x.ptr and x.num actually occupy the same storage?  It
>doesn't appear to require that assigning to one member actually affect
>the other member, because it is invalid to reference the other member
>after such an assignment (so how could you tell if it were affected?).
>Does C require that &x.ptr == ((char *) *)&x.num?
>
>Barry Margolin
>Thinking Machines Corp.
>barmar at think.com

Although they are not particularly designed as such, the Unisys A-Series
machines (descendents of the B6700) meet the description above.  That is,
security information is coded into the hardware pointer type, which can
only be constructed by secure hardware/software(operating system).

The usage shown may not be Standard C (I don't have a draft copy nearby to
check) but it is certainly conventional C.  Therefore, I believe that
the only way that "pointers" on such machines can be implemented securely
is through simulation.  That is, C pointers must be implemented as integer
subscripts into a large array which is defined through the standard
capability mechanism.  Due to the fungibility of C pointers, and conventional
C coding practices, it will probably work best if all the pointers point
into the same large array, although the Standard specifically doesn't
require this (I believe).

In any case, the new A-Series C compiler does implement pointers this way,
somewhat to the detriment of performance.  Not only are all malloc'ed items
placed in such a heap array, but all arrays which are pointed to, plus any
other automatics (including parameters) which are pointed to, are placed
in the heap array.  This requires management of a software-controlled stack
area in the heap array, inconjunction with the regular hardware-managed stack.

One consequence of this is that array which are never pointed to are more
efficient, because they save one level of indirection.  Admittedly, such arrays
are rare in C, but I'm glad Unisys went to the trouble of implementing
this optimization.

I hope to write more about the A-Series C compiler in the future.  It is
not based on any existing C implementations, and was written from scratch
as an ANSI C compiler for an unusual architecture.  As such, it has many
constructive lessons for those who believe that "All-the-world's-a-Vax/Sun".
-- 
Craig Jackson
dricejb at drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}