Re: [TUHS] Interesting commentary on Unix from Multicians.

At Fri, 8 Apr 2022 08:28:34 -0700, Larry McVoy <lm(a)mcvoy.com> wrote: Subject: Re: [TUHS] Interesting commentary on Unix from Multicians. I used Multics for a couple of my undergrad years at University of Calgary (along with a PDP-11/60 and then a PDP-11/44 and a VAX 11/780, with the DEC equipment running Unix of course: V7 on the 11s, and 32V then 3BSD and finally 4BSD on the VAX). I never really appreciated Multics as much then (except for its LISP and Emacs implementations), but have grown far more fond of it now that it is effectively gone. I think it would be most excellent, assuming it had kept up to modern needs, used modern languages (there was already a C compiler for it) and if modern hardware had continued to support it into the 64-bit era. The famous "everything is a file" description of Unix is wrong, or at least misleadingly incomplete -- the correct description is more like: "everything is a file _descriptor_"; whereas in Multics everything is actually just a memory array (except for some communications devices). Single Level Storage is an awesome concept and removes so many ugly hacks from algorithms that otherwise have to process data in files. Doing data processing with read and write and pipes is effectively working through a straw whereas SLS allows all (reasonably sized) data to be presented in entirely complete randomly accessible arrays just by attaching a "file" to a segment. Mmap() is a very poor replacement that requires a great deal extra bookkeeping that's next to impossible to hide from; and also there's the problem of the consistency semantics being different between the I/O based filesystems and direct memory mapping of their files, which Mmap() reveals, and which SLS eliminates (by simply not having any I/O mechanism for files in the first place!). Multics dynamic linking makes any unix-ish implementation look most ugly, incredibly insecure, and horribly inefficient. Unix shared libraries are bad hack to simulate what Multics did natively and naturally, with elegance, and with direct hardware security support. Both of these features of course strongly desire (for decent performance) either something like the original hardware-based segmented addressing scheme (e.g. as offered in Intel IA-32 and also tried to offer in the iAPX432), or hardware similar to what capability-based addressing schemes found in some research systems today [1]. Intel was never pressured strongly enough into improving the performance of segmented addressing and memory management in the IA-32 (because nothing (but OS/2?) really used it heavily the way a multics-like OS would have, and of course the iAPX432 also failed to deliver good performance), then AMD never carried full segmentation support forward into their 64-bit architecture and instruction set where it would have made larger scale multics-like systems more practical. [1] The experimental CHERI architecture is an example: CHERI: Memory Segmentation to Support Secure Applications "A segment mechanism that implements the capability model of safe, programmatic memory protection" http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2013essos-cheri.pdf "CHERI can do anything Multics could do: segmentation, paging, dynamic linking, ring-structured software" -- Peter G. Neumann in "An Interview with..." by Rick Farrow in ;login:, Winter 2017 vol. 42, no. 4 -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>