TUHS

tuhs@tuhs.org

28 participants
6496 discussions

by Dan Cross

I just heard that, after ATC'25, USENIX will be sunsetting the annual technical conference: this will apparently be the last one. I can't find any reference for it, though, and the web site mentions ATC'26 in Seattle? - Dan C.

18 minutes

Re: What is the intermediate code generated by the bc interpreter?

by jnc＠mercury.lcs.mit.edu

> From: Al Kossow > What was the name of the system(s)? From an early 'hosts' file: HOST MIT-RTS, [CHAOS 470,LCS 10/11],SERVER,UNIX,PDP11,[RTS,DSSR] I'd rather depend on that, than on my memory! (The names at the end are aliases.) While I was looking for a really early host file (I recall our early TFTP command had one; I don't think it was built into the command, but it might have been),~p I found a /jnk directory in MIT-CSR's root; it had a lot of interesting stuff in it. One particularly interesting one was 'kov': The idea of this kernel overlay scheme is to increase the amount of code that can be included in the UNIX kernel. This is done by reserving one of the I space segmentation registers (the highest free, usually KISA5 for non-split systems) and changing its value dynamically so as to map in the appropriate code as needed. I chose to use only one page register (limiting each KOV to 4Kw), in order to minimize the mapping overhead. I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 (and later BSD's)? That stuff is all poorly documented, and I'm not up for poring through both to compare them. This one was all done by Ken Harrenstien (KLH). Noel

16 hours, 8 minutes

The Official Announcement WRT the USENIX Annual Technical Conference

by Clem Cole

Casey Henderson-Ross is the ED of USENIX. Since the list would not accept her message, she asked me, as a former President, to send this to folks on the TUHS mailing list. ------------------------------- Folks, As you may already be aware, today we made an important announcement about the USENIX Annual Technical Conference via our mailing list. We want to share this news with you directly as well in case you do not currently receive USENIX email. Please read the statement in its entirety here: https://www.usenix.org/blog/usenix-atc-announcement If you don't know me, I've served on the USENIX staff since 2002 and have had the privilege of serving as Executive Director since 2012. USENIX and the Annual Technical Conference are both dear to me as I know they are to many of you. This is difficult news to share even as we're grateful to be celebrating 50 years of USENIX this year. I hope that you'll share your memories via the form mentioned in the statement and that we'll also see many of you at USENIX ATC '25 in Boston in July: https://www.usenix.org/conference/atc25 If you'd like to contribute to activities there, please contact me directly. Thanks to all of you for honoring the history of UNIX and for your support of USENIX and ATC (in its different names and forms) over the decades. Best, Casey Henderson-Ross ᐧ

18 hours, 10 minutes

Re: Unix Reverse Engineering

by jnc＠mercury.lcs.mit.edu

> From: Thalia Archibald > I'm working on building a decompiler from PDP-11 assembly to C to ease > studying old pre-C Unix sources. To start, I'm translating V5 `as` to > period-idiomatic C That's going to be a real trick; 'as' was written in PDP-11 assembler: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/as Noel

1 day, 5 hours

Re: What is the intermediate code generated by the bc interpreter?

by jnc＠mercury.lcs.mit.edu

> From: Tom Teixeira > before the RTS group at Project MAC (Called the DSSR group at that point om time, if anyone wants to look anything up.) > I got a BCPL compiler from somewhere and made some enhancements - such > as direct support for external variables and routines using a linker > rather than the pure BCPL global array. This entire toolchain, including all the source, has been preserved; the BCPL compiler, the linker ('bind', itself written in BCPL), and a number of tools (including an extra one, 'ldrel', written by the CSR group on the 5th floor). I have in the past put up some pieces for download, but I never got around to doing the whole thing, as there didn't seem to be any interest. We (CSR) started working with the toolchain because it included support for MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler source as output). That toolchain used a relocatable formet, .rel': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5 that I think was based on one DEC had done. CSR was working with a semi-real-time operating system, called 'MOS': https://gunkies.org/wiki/MOS_operating_system for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work on the Internet; e.g. all the BBN 'core' routers used in the early Internet used it, after the very first ones [written in BCPL, oddly enough], which had used ELF: https://gunkies.org/wiki/ELF_operating_system but BBN soon switched to MOS.) MOS was written in MACRO-11; we started working with MOS with the same toolchain SRI had used for it, which ran on TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So, we started working with the MACRO-11, and bind, on UNIX. I then decided I'd rather write code for our PDP-11 packet switches in this nifty language called C, used on UNIX, which nobody else knew about (at that point). The first step was to write 'ldrel', to convert a.out files (produced by the C compiler) to .rel files, so 'bind' could work with them. After a while, we decided we'd rather use 'ld' as our linker (I think because it supported demand loading from binary libraries, so we didn't have to manually specify every file to link). The DSSR group had long ago written 'relld', which converted .rel files (produced by MACRO-11) to a.out files, so that was pretty easy. There seems to be a version of the BCPL compiler which produces 8080 code. It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C compiler was not done at MIT). (I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and they seem to have done a lot of work with various micros. It may not have all the pieces it needs to work, though; it seems to need "/usr/simulators/s6502/s6502.body" from the DSSR machine.) Pity I didn't save a dump of that machine too; I was once looking for the source of the Algol interpreter, written on the Delphi machine, and made to run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine still existed, and he thought not. So we have the binary of that Algol interpreter, but not the source. Of course, it was probably written in MACRO-11, so a disassembler would produce a reasonable facsimile. And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the MIT archives - they might well have done, and Prof. Ward just didn't know that. Noel

1 day, 22 hours

What is the intermediate code generated by the bc interpreter?

by Jackson Helie G

I checked Dennis M. Ritchie's "Users' Reference to B" and found an example of implementing a B program at the bottom of the manual. It said that bc generates intermediate code suitable for ba, and then ba generates assembly code. So, I am curious about what the intermediate code generated by bc is?

1 day, 23 hours

Unix Reverse Engineering

by Thalia Archibald

Hello everyone, I'm working on building a decompiler from PDP-11 assembly to C to ease studying old pre-C Unix sources. To start, I'm translating V5 `as` to period-idiomatic C and have finished most of pass 1. Then I'll port it to Rust with a design better suited to static analysis, while keeping exact fidelity to the original. I'll do the same for `cc` and `ld`, after. I stumbled upon Warren's disaout[0] today, which made me wonder: What tools have people for reverse engineering Unix assembly sources or a.out binaries? Things like disassemblers or decompilers. I assume there's some versions of programs which are now only extant as binaries? Are there enough such binaries that were written in C to warrant writing a decompiler that understands the specific codegen of `cc` to improve accuracy? For now, I'm focusing on decompiling hand-written assembly, but I'm keeping this case in mind. Thanks! Thalia [0]: https://github.com/DoctorWkt/unix-jun72/tree/master/tools/disaout

2 days, 8 hours

Off topic: Books on Unix security?

by Aharon Robbins

Hi All. In a book I'm updating, I have the following references for Unix security. 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. 2. Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. One of my reviewers asked if these weren't "dusty references". So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. Thanks, Arnold

5 days, 8 hours

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The first "C" compiler wa an ephemeral state some time in the process > of its evolution. Dennis started with his B implementation and began to > add features he needed See: The Development of the C Language https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html for detail on the evolution. Noel

5 days, 13 hours

Re: Ken Thomson's email address?

by Jackson Helie G

If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler.

6 days, 1 hour

Jump to page:

2025

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