🚀 go-pugleaf

On 25 Dec 92 05:04:54 GMT, lindsay+@cs.cmu.edu (Donald Lindsay) said:
Nntp-Posting-Host: gandalf.cs.cmu.edu

lindsay> (Eric Koldinger) writes:

Eric> There's a fundamental difference between hardware and software
Eric> capabilities.  Software capabilities can be forged, however
Eric> improbable.

lindsay> You may have seen such a system, but some software-based
lindsay> systems really are fully secure. [ ... if capabilities are kept
lindsay> in capability segments only the priviledged sw can modify ... ]

Koldinger was evidently thinking only of capabilities protected with
random keys, like in Amoeba, and which can be scattered around in user
space. I would add to what Lindsay says that capability list
architectures whether hw or sw, have some intrinsic advantages in some
areas (e.g. revocation).

Eric> On an architecture like the AS/400, EVERY memory reference is
Eric> checked against a capability, and individual bytes can be
Eric> protected.

Uhmmm, the S/38 (and the AS/400 in this as in most low level respects is
an S/38 clone) MMU don't do this at all. The sw can define descriptors
to subobjects, but the smallest object protected by hw is 64KB.

Eric> Software capabilities are typically used to protect larger grained
Eric> objects, and are only checked when that object is "bound" to your
Eric> protection domain.

Quite the reverse actually...

lindsay> Agreed. However, conventional machines check every memory
lindsay> reference with an MMU. [ ... which may or may not offer fine
lindsay> grained access checking ... ]

lindsay> The AS/400 may support tiny objects, but does it gain much from
lindsay> doing so?

The hw only supports two object sizes, 16MB and, as a reprieve, 64KB,
which must be aligned on natural boundaries. The story of how the system
came to have *two* object sizes is amusing.

Initially the designers thought that given the very large address space
they could get away with wasting 24 bits of address space for every
object, just in case; this meant that all objects would begin at a
multiple of 2^24, thus reducing the capability table lookup to simple
array indexing, instead of requiring (pseudo) associative access like
other capability systems, where an object can begin at any address and
be any bytes long.

Unfortunately they found that 16MB was an inconvenient object size, and
thus they introduced a "small object" feature, for 64KB objects aligned
on an even boundary. But, but, and this is the amusing thing, once you
have two different object sizes, whether they are evenly aligned or not
does not matter, associative access is required exactly as in the
general case.

So the irony is that they designed into the hw an MMU with associative
access (simulated using hashing), which could have supported arbitrary
object sizes and alignments, while only supporting the 16MB and 64KB
naturally aligned object sizes, and then defining an extra sw layer to
fragment these fairly large objects into subobjects. My recollection may
be wrong, but I seem to remember that this misdesign was carried over
into the AS/400 architecture, as having 16MB/64KB hw objects and then sw
subobjects was actually visible to higher level sw.

--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta