Norman Hardy

> 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…

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…

"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…

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/102657988-05-01-acc.pdf

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

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