home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / arch / 11952 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  4.0 KB
  1. Path: sparky!uunet!utcsri!torn!spool.mu.edu!sdd.hp.com!swrinde!gatech!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.arch
  4. Subject: Re: IBM AS/400
  5. Message-ID: <PCG.92Dec27192202@decb.aber.ac.uk>
  6. Date: 27 Dec 92 19:22:02 GMT
  7. References: <1992Dec24.203452.22045@beaver.cs.washington.edu> <BzsIFK.EMF.2@cs.cmu.edu>
  8.     <1992Dec25.033918.3246@beaver.cs.washington.edu>
  9.     <Bzsu47.Lxv.2@cs.cmu.edu>
  10. Sender: news@aber.ac.uk (USENET news service)
  11. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  12. Organization: Prifysgol Cymru, Aberystwyth
  13. Lines: 72
  14. In-Reply-To: lindsay+@cs.cmu.edu's message of 25 Dec 92 05: 04:54 GMT
  15. Nntp-Posting-Host: decb.aber.ac.uk
  16.  
  17. On 25 Dec 92 05:04:54 GMT, lindsay+@cs.cmu.edu (Donald Lindsay) said:
  18. Nntp-Posting-Host: gandalf.cs.cmu.edu
  19.  
  20. lindsay> (Eric Koldinger) writes:
  21.  
  22. Eric> There's a fundamental difference between hardware and software
  23. Eric> capabilities.  Software capabilities can be forged, however
  24. Eric> improbable.
  25.  
  26. lindsay> You may have seen such a system, but some software-based
  27. lindsay> systems really are fully secure. [ ... if capabilities are kept
  28. lindsay> in capability segments only the priviledged sw can modify ... ]
  29.  
  30. Koldinger was evidently thinking only of capabilities protected with
  31. random keys, like in Amoeba, and which can be scattered around in user
  32. space. I would add to what Lindsay says that capability list
  33. architectures whether hw or sw, have some intrinsic advantages in some
  34. areas (e.g. revocation).
  35.  
  36. Eric> On an architecture like the AS/400, EVERY memory reference is
  37. Eric> checked against a capability, and individual bytes can be
  38. Eric> protected.
  39.  
  40. Uhmmm, the S/38 (and the AS/400 in this as in most low level respects is
  41. an S/38 clone) MMU don't do this at all. The sw can define descriptors
  42. to subobjects, but the smallest object protected by hw is 64KB.
  43.  
  44. Eric> Software capabilities are typically used to protect larger grained
  45. Eric> objects, and are only checked when that object is "bound" to your
  46. Eric> protection domain.
  47.  
  48. Quite the reverse actually...
  49.  
  50. lindsay> Agreed. However, conventional machines check every memory
  51. lindsay> reference with an MMU. [ ... which may or may not offer fine
  52. lindsay> grained access checking ... ]
  53.  
  54. lindsay> The AS/400 may support tiny objects, but does it gain much from
  55. lindsay> doing so?
  56.  
  57. The hw only supports two object sizes, 16MB and, as a reprieve, 64KB,
  58. which must be aligned on natural boundaries. The story of how the system
  59. came to have *two* object sizes is amusing.
  60.  
  61. Initially the designers thought that given the very large address space
  62. they could get away with wasting 24 bits of address space for every
  63. object, just in case; this meant that all objects would begin at a
  64. multiple of 2^24, thus reducing the capability table lookup to simple
  65. array indexing, instead of requiring (pseudo) associative access like
  66. other capability systems, where an object can begin at any address and
  67. be any bytes long.
  68.  
  69. Unfortunately they found that 16MB was an inconvenient object size, and
  70. thus they introduced a "small object" feature, for 64KB objects aligned
  71. on an even boundary. But, but, and this is the amusing thing, once you
  72. have two different object sizes, whether they are evenly aligned or not
  73. does not matter, associative access is required exactly as in the
  74. general case.
  75.  
  76. So the irony is that they designed into the hw an MMU with associative
  77. access (simulated using hashing), which could have supported arbitrary
  78. object sizes and alignments, while only supporting the 16MB and 64KB
  79. naturally aligned object sizes, and then defining an extra sw layer to
  80. fragment these fairly large objects into subobjects. My recollection may
  81. be wrong, but I seem to remember that this misdesign was carried over
  82. into the AS/400 architecture, as having 16MB/64KB hw objects and then sw
  83. subobjects was actually visible to higher level sw.
  84.  
  85. --
  86. Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  87.   E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  88.   alle orecchie del suo divino protettore, il dio della barzelletta
  89.