Norman Hardy

From the same cape-lore website, Tymshare also devloped GNOSIS (Great New Operating System In the Sky[0] which became KeyKos. A secure capability-based operating system with transparent persistence. KeyKOS inspired EROS ( Extremely Reliable Operating System). http://www.cap-lore.com/Agorics/Library/keykosindex.html https://en.wikipedia.org/wiki/EROS_(microkernel) [0] Sky .. like "clouds" existed in the 1970s? :)

Essays, notes and memoirs going back to the 1950s by Norman Hardy, one of the developers of GNOSIS and its successor KeyKOS, at http://cap-lore.com/

The starting point for this set of pages is http://www.cap-lore.com/CapTheory/ and from there it recommends http://habitatchronicles.com/2017/05/what-are-capabilities/ as basic intro (and so do I). The author was an architect of a 1970s/80s OS that's little known but that apparently influenced seL4 a lot. These pages aren't introductory but I'm glad they exist. A sensory key was a kind of transitive attenuator: it's like a read-only reference to an object such that if you use it to fetch a property from the object, the reference to the property that you get back is also a sensory key. (This is my understanding but I may be confused; I've only read about this OS.)

Specialized hardware/generalized hardware is one of the classic 'wheels of reincarnation' in computer tech: http://www.cap-lore.com/Hardware/Wheel.html But looking back over the last 20 years, at least for the silicon paradigm, I think we may finally be in the last turn of the wheel. The trend back towards specialized hardware (for audio, video, encryption, NN, servers vs smartphones) seems fairly inexorable. There's no CPU architecture remotely on the horizon which is general and blows away everything else for flexibility and speed. Even specialized hardware like GPUs are starting to see their lunch eaten by ultra-specialized ASICs and TPUs.

> OS/400 -- now called IBM i -- sounds like it was ahead of its time: That's because it's the last remnant of Atlantis. https://people.cs.clemson.edu/~mark/fs.html > The IBM Future System (FS) project was a design effort to succeed the IBM S/370 architecture that was adopted company wide in 1971. FS was based on a single-level store with automatic data management. The project is reputed to have cost more than $1B when it was cancelled in February 1975, but the single-level store idea was adopted by System/38, AS/400, and iSeries. Single-level store is IBM's cutesy way of saying that there's no application-level distinction between disk and RAM: It's all data, applications access data (or don't, depending on a security model), and the OS handles persistence the same way it handles caching; that is, transparently. Anyway, security was important to IBM, particularly the security to be free from people making clones of FS hardware. This had unfortunate effects on the systems's comprehensibility: http://www.cap-lore.com/CapTheory/KK/FS.html > Some suggest that this memo[0] was the beginning of the end of IBM’s Future System. The section of the memo with “security” in the heading, concerns keeping the architecture secret, from most of those working on the project. Quote: >> Tight security prevents a potential thief from stealing a system design. But good communication is necessary to design a system that is worth stealing. The recent version of the RIPON architecture has…

"Your argument here being that a mysterious group of old-school TCSEC people understood microarchitectural side channel attacks years ago, so much so that we could have eliminated them in the 1990s, but chose to say nothing about them --- until now." There you go misrepresenting and slandering folks again. What I've said since I joined HN is that a group of people in military, private companies, and academia did the following: invented INFOSEC, did assessments/pentests, and tried to build clean-slate systems that were secure; regularly published that stuff in security publications and/or conferences [1][2]; built products with those methods [3][4][5]; put it in computer security texts to teach next generation [6]; led others to do the same [7][8][9]. This large group of people doing tens of millions of dollars of research, development, education, and outreach over 40-50 year period was anything but a "mysterious group." They were a group you and a lot of other people were ignoring, dismissing, mischaracterizing, and so on. That's an entirely, different thing that says more about you and others that ignored them than the people working hard to secure our systems publishing how to do it for everyone's benefit for decades on end. I find it interesting that many in INFOSEC ignore or trash talk their pioneers so much. These people invented the field, made the landmark contributions, and addressed many fundamental problems from early 60's to early 90's. Mainstream INFOSEC and…

Reminded me of http://www.cap-lore.com/code/Scheme/equal.html which gives a equal? which works on cyclical structures.

It's also known as Sutherland's Wheel of Reincarnation: http://www.cap-lore.com/Hardware/Wheel.html

Nasser is said to have been inspired by Kutuzov during the 6-day war: having first lured the israelis across the Sinai and deep into egypt, the only thing he subsequently needed to do was wait for General Winter to arrive... And the MCP said unto Cain, Where is Abel thy ⊓-er? And he said, I know not: Am I my meter's keeper? http://cap-lore.com/CapTheory/upenn/Gnosis/Gnosis.html

Ivan Sutherland described the reason [1] why PCs won a long time ago. Basically a custom tool may do a thing "better" than a general purpose tool for a while, but eventually, because more resources are spent improving the general tool, the generalized tool will be able to do the same thing as the specialty tool, but more flexibly and economically. [1] http://www.cap-lore.com/Hardware/Wheel.html

Microkernels + userspace drivers end up with too many context switches. This has been the main issue with microkernels. Then you add performance sensitive services in the "microkernel" and it stops being micro! Note that KeyKOS has a microkernel arch. but they called it "nanokernel" to distinguish from all the other fat "microkernels". They even prototyped a Unix service called "KeyNIX". See http://cap-lore.com/CapTheory/upenn/NanoKernel/NanoKernel.html

I am familiar with that as "The Law of Recapitulation" based on a discarded idea from Biology. I can't find any references now, but the idea was that the evolution of mainframe computers (memory sizes, features such as caches, and so on) was repeated years later by minicomputers and even later by microcomputers. Knowing this I was able to design very advanced micros in the early 1980s since I knew what the future would be like. "The Wheel Of Reincarnation" described by Ivan Sutherland is closely related, but is based on the idea that computing history is more like a spiral than a straight line, so the future is more similar to the past than to the present. http://www.cap-lore.com/Hardware/Wheel.html

The KeyKOS mainframe operating system, to which users connected with terminals, had an interesting scheduling and resource metering system: http://www.cap-lore.com/CapTheory/KK/Arch/Three.Special.html#meterkey Users could buy CPU time and grant portions of it to other users in the system (say, their employees) via keys, who could in turn grant resources to other users/ subprocesses recursively, resulting in a metering tree. The programming language Joule, which was inspired by it, used this system too: http://www.erights.org/history/joule/MANUAL.BK8.pdf The Sel4 and Genode operating systems as well

http://cap-lore.com/code/BloomAnno.html is a much shorter page that has a lot more interesting stuff about Bloom filters in it in a lot fewer words.

... Aa-and I’m being stupid, because there were of course also “persistent” OSes like KeyKOS[1], where a memory image (swapped in, modified, and swapped out as necessary) is essentially the only way for a program to exist. (Good news: capability access control is easy to program to and has entirely intuitive dynamic behaviour. Bad news: noöne has worked out how to bootstrap this dynamic behaviour from a static set of rules in a reasonably modular way, to the point that making a system which can hibernate but never shut down actually starts to look like a reasonable solution.) [1]: http://cap-lore.com/CapTheory/upenn/

Does anyone remember the actor based programming language Joule [1]? It had a manual, and maybe some kind of private prototype, but never a public release as far as I know. How does Pony relate to Joule? They seem to be on a continuum, what with Actors, object capabilities etc. [1] http://www.cap-lore.com/Agorics/Library/joule.html

Sounds interesting. Any links and references for "Fully Distributed Representation"? This is what I found when I Googled the quoted phrase: http://www.cap-lore.com/RWC97-kanerva.pdf. Skimming the paper this reminds me of word2vec and similar techniques for embedding words into vector spaces but instead of using XOR the embedding is accomplished with another neural network. Here's a link to a good description of the embedding process: https://towardsdatascience.com/neural-network-embeddings-explained-4d0…

http://www.cap-lore.com/Hardware/Wheel.html We’re currently rolling around back to a new era of lots of specialized chips.

> I don't think privilege escalation is really related because that needs to modify state you should not have access to. But in a capability-based OS, privilege is all about the keys you hold, no? So assuming a malicious process can copy keys from other processes, can the OS detect and prevent the malicious process from using the key? I tried reading up on KeyKOS[1] and there was very little info on what exactly a key is and how it is verified by the OS, at least that I could see. [1]: http://cap-lore.com/CapTheory/KK/Arch/

I have also made bulleted notes of this article a few months back: https://github.com/hierophantos/capable Talking to one of the "O-Cap Gang", Norm Hardy (http://www.cap-lore.com/CapTheory/) a few weeks ago, he said, to the point of creating secure distributed computing architectures: "Object capabilities are not easy, but they're the only way I see forward." I'm biased to agree.

Hi, here are some modern resources. First, what's the problem? http://www.cap-lore.com/CapTheory/ConfusedDeputy.html What are capabilities? http://habitatchronicles.com/2017/05/what-are-capabilities/ Is there someplace with a massive pile of links? https://github.com/dckc/awesome-ocap Yes, capabilities are abstract and simple. Don't worry if you don't get it at first.

I wrote many of the Keykos papers and can answer most questions you might have. For instance, can sandstorm do confinement as described at http://cap-lore.com/CapTheory/Confine/ ?

Regarding the printf (pre)history see my old comment: https://news.ycombinator.com/item?id=3964475 printf is based on the idea implemented as early as 1956, next year it will be 60 years since! 1956: Fortran I: PRINT 1, X 1 FORMAT (F10.2) Fortran was invented by John Backus and there was already a finished compiler in 1956. I/O in the first Fortran, I believe including the FN.M syntax, was implemented by Roy Nutt, also one obvious genius: http://www.cap-lore.com/stories/Assembler.html "There were a few pages of description of a new assembler format for the IBM 704 that differed considerably from the NYAP that we were using." (That) "704 assembler, originally called SAP, was written in its own language by Roy Nutt."

Ultimately I think any truly autonomous agent would be out-competed by one that has a human in the loop modifying the code to adapt to the market (e.g. customer development). But it's a cool concept. Some similar musings from history: http://www.research.ibm.com/massive/bump.html http://www.cap-lore.com/Agorics/Library/agoricpapers.html

See also "Agoric computing", http://www.cap-lore.com/Agorics/Library/agoricpapers.html ...

I've written a little bit before about KeyKOS/GNOSIS, which is the capability operating system used by Tymshare to host their timesharing language services on IBM mainframes, in the 70s and 80s. From a comment 3 years ago I'll just repost the relevant part: > KeyKOS (developed by Tymshare for their commercial computing services in the 1970s) - A capability operating system. If everything in UNIX was a file, then everything in KeyKOS was a memory page and capabilities (keys) to access those pages. The kernel has no state that isn't calculated from values in the virtual memory storage. The system snapshots the virtual memory state regularly. There are subtle consequences from this. Executing processes are effectively memory-mapped files that constantly rewrite themselves, with only the snapshots being written out. Snapshotting the virtual memory state of the system snapshots everything -- including the state of running processes. There's no need for a file system, just a means to map names to sets of pages, which is done by an ordinary process. After a crash, processes and their state are internally consistent, and continue running from their last snapshot. For those who are intrigued, there's a good introduction, written in 1979, by the system's designers available here: http://cap-lore.com/CapTheory/upenn/Gnosis/Gnosis.html (It was GNOSIS before being renamed KeyKOS.) And a later document written in the 90s aimed at UNIX users making the case:…

Not exactly chiptune, but I feel the Floppotron ( https://www.youtube.com/watch?v=e-WakfBNHD0 ) is more or less in a straight line of descent from the ancients: https://archive.computerhistory.org/resources/access/text/2015/06/1026… Tymes: ...I found that if I gave a write command to the tape unit and then aborted the write command before it got past the interrecord gap, I could start and stop the tape as often as maybe 300 times a second, which is in the acoustic range. So you could make a lot of noise with those things. Hardy: He got them to play music. Tymes: So I wrote the Stars and Stripes Forever. I used the console speaker for the piccolo. It had a drum printer, which I used for the percussion. And I had a row of tape units all synchronized so that they were all pulsing together for the trombones. ... Tymes: We put the doors to the tape unit half way down so that they would radiate the sound really good. And you could feel it in your chest. It would go bom, bom, ba bam bom. The whole building would shake when that program ran. EDIT: a picture of this "expensive tracker" (~USD 30 million in 2024?) may be found in http://www.cap-lore.com/Hardware/steam_42-43.pdf

Oh, Norm Hardy's wife. Tymnet was interesting. It was a virtual circuit-switched system for keyboard terminals. There was a central control machine, and a bunch of dumb switching nodes. The central control machine (an SDS-945 originally) would set up a route and send out "route channel 24 to channel 57" commands to each node. The nodes just forwarded packets per the set route. If the control machine went down, all routes stayed working, but new ones could not be set up. There was a second control machine that could take over if needed. Nodes had a queue for each virtual circuit, and flow control. It wasn't end to end raw packets. In the days of expensive long haul bandwidth, this was essential. Pure datagram networks only work because our long-haul connections today have huge bandwidth. Datagram networks can't really handle congestion in the middle of the network. Virtual circuit networks can. Which is why, in the early 1970s, it looked like virtual circuit networks were the future. Even the original ARPANET had node to node flow control. The Tymnet "backbone" was originally only 2400 to 4800 baud, so they had major lag problems. To help with this, they used local echo when possible, so local typing didn't lag. You'd type in a line, and at the end of the line, the whole line went across the network. The connection could shift from local to remote echo seamlessly. (Telnet, for the Internet, can do local echo, too, but Berkeley didn't put that in their BSD Telnet, so it…

What they're trying to get across is that this is not a Bad USB [0] attack, but an Evil Maid [1] attack. In either case, the attacker does not need to rush. To commit a Bad USB attack, the attacker deputizes you and uses your confusion [2] to get you to insert a dangerous peripheral device, on your own time. In an Evil Maid attack, the attacker patiently waits until you trust (read as: "are vulnerable to") their physical presence, and then inserts a dangerous peripheral device. To use your analogy, in the former case, the murderer poisoned your food at the grocer's, and you unwittingly dose yourself when you make your meal. In the latter case, the murderer spends time getting to know you and letting you trust them, and then one day, when you go to the bathroom, they come in and shoot you like Vincent Vega. [0] https://en.wikipedia.org/wiki/USB_flash_drive#BadUSB [1] https://en.wikipedia.org/wiki/Evil_maid_attack [2] http://www.cap-lore.com/CapTheory/ConfusedDeputy.html