TUHS September 2021

tuhs@tuhs.org

43 participants
25 discussions

Start a nNew thread

Re: [TUHS] Thompson trojan put into practice

by jnc＠mercury.lcs.mit.edu

https://googlethatforyou.com/?q=Tom%20Duff%20Virus Noel

3 years, 3 months

Thompson trojan put into practice

by arnold＠skeeve.com

This is FYI. No comment on whether it was a good idea or not. :-) Arnold > From: Niklas Rosencrantz <niklasro(a)gmail.com> > Date: Sun, 19 Sep 2021 17:10:24 +0200 > To: tinycc-devel(a)nongnu.org > Subject: Re: [Tinycc-devel] Can tcc compile itself with Apple M1? > > > Hello! > > For demonstration purpose I put my experiment with a compiler backdoor in a > public repository > https://github.com/montao/ddc-tinyc/blob/857d927363e9c9aaa713bb20adbe99ded7… > > It's part of my academic project to work on provable compiler security. > I tried to do it according to the "Reflections on Trusting Trust" by Ken > Thompson, not only to show a compiler Trojan horse but also to prove that > we can discover it. > What it does is inject arbitrary code to the next version of the compiler > and so on. > > Regards \n

3 years, 3 months

ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe)

by Dan Cross

One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). I'm curious about other peoples' thoughts on the talk and the overall topic? https://www.youtube.com/watch?v=36myc8wQhLo - Dan C.

3 years, 3 months

RegExp decision for meta characters: Circumflex

by Douglas McIlroy

> Maybe there existed RE notations that were simply copied ... Ed was derived from Ken's earlier qed. Qed's descendant in Multics was described in a 1969 GE document: http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condens…. Unfortunately it describes regular expressions only sketchily by example. However, alternation, symbolized by | with grouping by parentheses, was supported in qed, whereas alternation was omitted from ed. The GE document does not mention character classes; an example shows how to use alternation for the same purpose. Beginning-of-line is specified by a logical-negation symbol. In apparent contradiction, the v1 manual says the meanings of [ and ^ are the same in ed and (an unspecified version of) qed. My guess about the discrepancies is no better than yours. (I am amused by the title "condensed guide" for a manual in which each qed request gets a full page of explanation. It exemplifies how Unix split from Multics in matters of taste.) Doug

3 years, 3 months

Re: [TUHS] Unix for PDP11/20 w/o mmu or paging option

by jnc＠mercury.lcs.mit.edu

> From: Roland Huisman > I have a PDP11/20 and I would love to run an early Unix version on > it. ... But it seems that the earliest versions of Unix do not need the > extra memory. Does anyone have RK05 disk images for these early Unix > versions? Although the _kernel_ source for V1 is available: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1 most of the rest is missing; only 'init' and 'sh' are available. So one would have to write almost _everything_ else. Some commands are available in PDP-11 assembler in later versions, and might be movable without _too_ much work - but one would have to start with the assembler itself, which is luckily in assembler. If I were trying to run 'UNIX' on an -11/20, I think the only reasonable choice would be MINI-UNIX: https://gunkies.org/wiki/MINI-UNIX It's basically V6 UNIX with all use of the PDP-11 memory management removed. The advantage of going MINI-UNIX is that almost all V6 source (applications, drivers, etc) will run on it 'as is'. It does need ~56KB of main memory. If you don't have that much on the -11/20, LSX (links in the above) would be an option; it's very similar to MINI-UNIX, but is trimmed down some, to allow its use on systems with less main memory. I'm not sure if MINI-UNIX has been run on the -11/20, but it _should_ run there; it runs on the -11/05, and the only differences between the /20 and the /05 are that the /20 does not have the RTT instruction (and I just checked, and MINI-UNIX doesn't use RTT), and SWAB doesn't clear the V condition code bit. (There are other minor differences, such as OP Rn, (Rn)+ are different on the -11/20, but that shouldn't be an issue.) Step 1 would be to get MINI-UNIX running on an -11/20 under a simulator; links in the above to get you there. Noel

3 years, 3 months

Re: [TUHS] Unix for PDP11/20 w/o mmu or paging option

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The KS11 MMU for the 11/20 was built by CSS ... I think Noel has done > more investigation than I have. I got a very rough description of how it worked, but that was about it. > I'm not sure if the KS11 code is still there. I did not think so. No, the KS11 was long gone by later Vn. Also,I think not all of the -11/20 UNIX machines had it, just some. > The V1 work was for a PDP-7 Actually, there is a PDP-11 version prior to V2, canonically called V1. The PDP-7 version seems to be called 'PDP-7 UNIX' or 'V0'. > I'm fairly sure that the RK05, used the RK11-D controller. Normally, yes. I have the impression that one could finagle RK03's to work on the RK11-D, and vice versa for RK05's on the RK11-C, but I don't recall the details. The main difference between the RK11-C and -D (other then the implementation) was that i) the RK11-C used one line per drive for drive selection (the -D used binary encoding on 3 lines), and ii) it had the 'maintenance' capability and register (al omitted from the -D). > The difference seems to have been in drive performance. Yes, but it wasn't major. They both did 1500RPM, so since they used the same pack format, the rotational delay, transfer rate, etc were identical. The one peformance difference was in seeks; the average on the RK01 was quoted as 70 msec, and 50 msec on the RK05. > Love to see the {KT11-B prints] and if you know where you found them. They were sold on eBait along with an -11/20 that allegedly had a KT11-B. (It didn't; it was an RK11-C.) I managed to get them scanned, and they and the minimal manual are now in Bitsavers. I started working on a Tech Manual for it, but gave up with it about half-way done. > I wonder if [our V1 source] had the KS-11 stuff in it. No; I had that idea a while back, looked carefully, our V1 listings pre-date the KS11. > From: Roland Huisman > There is a KT11B paging option that makes the PDP11/20 a 18 bit > machine. Well, it allows 2^18 bytes of main memory, but the address space of the CPU is still2^16 bytes. > It looks a bit like the TC11 DECtape controller. IITC, it's two backplanes high, the TC11 is one. So more like the RK11-C... :-) > I have no idea how it compares to the later MMU units from the > software perspective. Totally different; it's real paging (with page tables stored in masin memory). The KT11-B provides up to 128 pages of 512 bytes each, in both Exec and User mode. The KT11-C, -D etc are all segmentation, with all the info stored in registers in the unit. > I wonder is there is some compatibility with the KT11-B [from the KS11] I got the impression that the KS11 was more a 'base and bounds' kind of thing. Noel

3 years, 3 months

Unix for PDP11/20 w/o mmu or paging option

by Roland

Hello Unix fanatics, I have a PDP11/20 and I would love to run an early Unix version on it. I've been working on the hardware for a while and I'm getting more and more of the pieces back online again. The configuration will be two RK05 hard disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. Unfortunately I don't have a MMU or paging option. But it seems that the earliest versions of Unix do not need the extra memory. Does anyone have RK05 disk images for these early Unix versions? That would be a great help. Otherwise it would be great to have some input about how to create a bootable Unix pack for this machine. A bit about the hardware restoring is on the vcfed forum:https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-ve… Booting RT11 from RK05https://youtu.be/k0tiUcRBPQATU56H tape drive back onlinehttps://youtu.be/_ZJK3QP9gRA Thanks in advance!Roland Huisman

3 years, 3 months

RegExp decision for meta characters: Circumflex

by markus schnalke

Hoi, I'm interested in the early design decisions for meta characters in REs, mainly regarding Ken's RE implementation in ed. Two questions: 1) Circumflex As far as I see, the circumflex (^) is the only meta character that has two different special meanings in REs: First being the beginning of line anchor and second inverting a character class. Why was it chosen for the second one? Why not the exclamation mark in that case? (Sure, C didn't exist by then, but the bang probably was used to negate in other languages of the time, I think.) 2) Symbol for the end of line anchor What is the reason that the beginning of line and end of line anchors are different symbols? Is there a reason why not only one symbol, say the circumflex, was chosen to represent both? I currently see no disadvantages of such a design. (Circumflexes aren't likely to end lines of text, neither.) I would appreciate if you could help me understand these design decisions better. Maybe there existed RE notations that were simply copied ... meillo

3 years, 3 months

Re: [TUHS] desiderata

by Douglas McIlroy

You can check the Computer History Museum's holdings on line. If they don't have the documents already, they would probably like them. The Living Computer Museum in Seattle had a working blit on display. If they don't already have the manual, I'm sure they would love to have one. Alas, their website says they've "suspended all operations for now", a result of the double whammy of Covid and the death of their principal angel, Paul Allen.

3 years, 3 months

desiderata

by Andrew Hume

more garage cleaning this last weekend. i came across some memorabilia from my time at Bell Labs, including a lovely article titled The Electrical Properties of Infants Infants have long been known to grow into adults. Recent experiments show they are useful in applications such as high power circuit breakers. Not to mention a lovely article from the “Medical Aspects of Human Sexuality” (July 1991) titled “Scrotum Self-Repair”. the two items are 1) “Documents for UNIX Volume 1” by Dolotta, Olson and Petrucelli (jan 1981)” 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes the full manual (including man pages) and circuit diagrams. i’d prefer to have them go to some archival place, but send me a private email if you interested and we’ll see what we can do. andrew

3 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS September 2021