Described in ISCA’s Information Security magazine as a "designated holist," Peter G. Neumann has devoted most of his decades-long career to the big-picture view of computer systems, security, and risk avoidance. After earning his Ph.D. at Harvard in 1961, Neumann went to work at Bell Laboratories, where he was part of the pioneering group that developed the Multics operating system. Ten years later, he moved to SRI International, where he now, at the age of 81, continues to break new ground with clean-slate architecture research funded by the U.S. Defense Advanced Research Projects Agency (DARPA). He also still moderates the ACM Forum on Risks to the Public in the Use of Computers and Related Systems, adding commentary and insight to a seemingly endless stream of tales about human and machine-driven error.
You studied applied math at Harvard. What drew you to computer science? Your website mentions a summer job with the Naval Ordnance Lab using an IBM Card-Programmed Calculator; were you interested in computers before that job, or did the position spark your interest?
I had always been fascinated by math in high school, and was a math major as an undergrad at Harvard. In spring 1953 of my junior year, I took Howard Aiken’s course on the ‘switching theory’—which was really the basis for Boolean logic applied to realistic computer hardware circuits. In that there was no computer science at that time, all of the computer-related courses during those early years were listed under ‘Applied Mathematics’ in the catalog. A friend of my parents suggested a ‘student aid trainee’ summer internship in Silver Spring, MD, so I cut my eyeteeth programming a complex matrix inversion routine on an IBM CPC, which effectively had a microcode plugboard that made it look like a three-address calculator with four registers. A foot-long card deck included the linear program (no loops) and the matrix data, which when run through the CPC punched two new cards, which when placed at the end of the card deck and run again punched out four cards. This process was then repeated until the matrix inversion was completed; very primitive, but it was a great learning experience.
"I cut my eyeteeth programming a complex matrix inversion routine on an IBM CPC (Card-Programmed Calculator)."
You spent the first 10 years of your career at Bell Labs, where you helped lead the development of Multics. How did you come to be involved with the project?
I owe a lot to Vic Vyssotsky. On the first day of work after New Year’s Day in 1965, Vic and I happened to be walking in from the parking lot together, and I asked what he was working on. He said, "Why don’t you join me?" as he was just going into the very first organizational meeting for Bell Labs’ participation with MIT in the as-yet-unnamed groundbreaking new computer project that today we would call clean-slate total-system architecture. I did. It, of course, involved new hardware (with virtual memory, segmentation, paging, an input-output coprocessor), new operating system concepts, and was implemented in a high-level programming language rather than assembly code.
What prompted the move to SRI? I gather Bell Labs stopped supporting Multics shortly before you left; was that what inspired you to search for a new position?
Actually, my mother had died in early 1970 (my father nine years before), and I suddenly had some new mobility. Also, the corporate culture of Bell Labs was beginning to change, although the UNICS/UNIX work of Ken Thompson, Dennis Ritchie, (and) Brian Kernighan certainly kept some of the old feeling of fabulous research and development. About then, Lotfi Zadeh invited me to teach at Berkeley for the academic year 19701971. At the time, I had three children aged 3, 5, and 8 (Fibonacci numbers, which made them easy to remember), whom I wound up raising more or less by myself for 17 years. In the spring of 1971, Jack Goldberg was the long-time head of the computer science lab at what was then Stanford Research Institute, whom I had known since David Huffman invited me to teach at Stanford in the spring of 1964. Jack invited me to consult for a week and help set up the CSL research agenda. That led to an offer to join what later became SRI International. The kids and I really enjoyed California, so we decided to stay.
Can you tell me a bit about your work on CTSRD and the clean-slate project? If I understand correctly, you have explored tagged architectures and hardware specifications that are formally verifiable. What are the latest developments?
The history of this goes back to the Provably Secure Operating System that we did at SRI beginning in 1973. That was a tagged capability clean-slate hardware-software co-design effort where every module was specified in a formal specification language that Larry Robinson and Karl Levitt created, with a formal basis evolving from Bob Boyer’s work, with the architecture later really cleaned up with Rich Feiertag. The current joint projects between SRI and the University of Cambridge draw heavily on the experiences from Multics and PSOS.
"The old adage seems to prevail among folks who have not been so exposed: To a person with a hammer, everything looks like a nail."
In the 1970s, formal methods were impractical unless everything was formally specified (as it was in PSOS). Today, we have built the SRI formal analysis tools into the hardware specification/development tools so that we can indeed, rather straightforwardly, prove properties about the hardware, and then use the Robinson-Levitt theorem from the PSOS project to prove properties of the low-layer software that use proofs of properties about the hardware, giving much greater assurance than you can get otherwise.
You have moderated the ACM group on risk for years. Thanks to that work, and to your book on computer-related risks, it has become apparent that most technology failures follow one of a small, set number of patterns. Do you have a favorite failure?
Actually, I have many favorites. What is fascinating is the huge diversity of causes and effects. Causes are often attributable to a combination of problems relating to inadequate requirements, inaccurate specifications, flawed system architectures, weak hardware, poor software engineering practices, human foibles, and malicious actions (for example). Effects span all fields of endeavor. So, I really do not think there are just a few patterns.
You are known for advocating a holistic view of computers and taking, for instance, human error and human behavior in general into account. Are people growing more receptive to this message?
Yes and no. People who have been reading the Risks Forum are repeatedly exposed to that holistic view, partly by my editorial comments and partly by the intrinsic nature of the ongoing discussions of what demonstrably turn out to be holistic problems. On the other hand, the old adage seems to prevail among folks who have not been so exposed: To a person with a hammer, everything looks like a nail. That adage applies equally to other artifacts and other disciplines. Examples include people who see everything as a hardware problem, or a software problem, or an algorithm problem, or a network problem, or a security problem, or a human safety problem. The holistic view is that those concepts are often interrelated. One of my very favorite quotes is one that Butler Lampson attributes to Roger Needham and Roger attributed to Butler: If you believe that cryptography is the answer to your problem, then you do not understand cryptography, and you do not understand your problem. That, of course, also applies to many other disciplines.
When you were still a student at Harvard, you discussed simplicity with Albert Einstein over breakfast, and you have mentioned that he told you he thought Brahms was "burning the midnight oil trying to be complicated." What do you make of Brahms?
I love Brahms’ music, because of its carefully integrated complexity, but also its harmonic and aesthetic beauty and the innovations it introduced at the time he was composing.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment