[email protected] (John McKown) writes: > Yeah. The hardware designers should have made an "eXecute" bit to go > along with the other "metadata" bits (such as key and change) so that > a attempting to branch to a frame which is not marked "eXecute" would > cause an exception. But even that doesn't help since you could still > "wild branch" into a code sequence. Maybe we should just all go to the > IBMi series. Lots of really advanced ideas in that box.
the capability hardware bit was dropped in the migration from s/38 to AS/400. https://en.wikipedia.org/wiki/IBM_System/38 and https://en.wikipedia.org/wiki/IBM_System/38#Distinctions System/38 was one of the few commercial[citation needed] computers with capability-based addressing. (The earlier Plessey 250 was one of the few other computers with capability architecture ever sold commercially). Capability-based addressing was removed in the follow-on AS/400 and iSeries models.[1] ... snip ... Much of S/38 is touted as having been simplified version of the failed Future System effort ... some past posts http://www.garlic.com/~lynn/submain.html#futuresys and Future System had picked up a lot of the ideas from things like Multics (read, write, and execute permsissions referenced in section 1.1 Segment Addressing) http://multicians.org/exec-env.html Some of the CTSS people had gone to the 5th flr to do Multics, others had gone to the IBM science center on the 4th flr and did virtual machines, online applications, internal network, and a bunch of other stuff. Note that in the 70s, one of the virtual machine based online commercial service bureaus had done a capabiity-based 370 operating system called gnosis. When M/D bought the company, gnosis was spun off as independent business (i was brought in to evaluate gnosis as part of the spin off). Since then some number of subsequent capability based operating systems have been done for other platforms based on gnosis design and principles. KeyKOS - A Secure, High-Performance Environment for S/370 http://cap-lore.com/CapTheory/upenn/Key370/Key370.html http://www.cap-lore.com/CapTheory/KK/ some discussion of Keykos (secure) use of mapping hardware http://www.cap-lore.com/CapTheory/PrivMap.html part of Gnosis/KeyKOS was raising the application abstraction ... they demoed a set of redone ACP/TPF applications that ran faster on KeyKOS than on TPF (on the same hardware, in addition to providing much higher integrity level). we were brought in to help wordsmith some cal. state legislation. One of the things they were doing was data breach notification law. Little or nothing was being done about the breaches and it was hoped that the publicity from the notifications would prompt action. An issue was that institutions normally take security measures in self-protection, the problem in most of the breaches was that the institutions weren't are risk it was the public. trivia: since the cal. state legislation, several other states have passed similar bills and there have been a dozen or so federal (state pre-emption) bills introduced (none passed), about evenly divided to similar to cal. original legislation and those that would effective eliminate requirement for notification (even tho still called data breach notification legislation). In the 90s, the major internet exploits were from buffer length & stack baced issues in C-language based implementations (extra long input, in same cases containing instructions that overlayed other things). As an aside, the original mainframe implementation was in vs/pascal which had none of the vulnerabilities epidemic in C-language based implementations. In any case around turn of the century, some of the machines introduced a "no-execute" bit (inverse of execute bit) ... aka data-only areas from which instructions were *NEVER* fetched ... NX bit https://en.wikipedia.org/wiki/NX_bit in i86 ... first added by AMD for its i86 64-bit machines https://en.wikipedia.org/wiki/NX_bit#x86 other trivia: future system (& s/38) also did one-level store like (ibm's) tss/360 and multics. The simplified s/38 implementation did scatter allocation across all available disk drives ... as a result an integral single filesystem backup had to be done (involving all disks being idle) ... and any single disk failure ... would require complete filesystem restore. For most small s/38 configurations with only a couple disk drives it wasn't much of problem, but failed to scaleup to mainframe configurations with potentially hundreds of disk drives. I had done a page-mapped filesystem for cp67/cms ... later moved to vm370/cms ... and would pontificated that I avoided all the TSS/360 performance pitfalls (getting 3 times or better throughput than standard cms filesystem). With the failure of Future System, it seemed to contributed to a very jaundiced opinion of page-mapped filesystems inside most of (mainframe) IBM. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
