unused0

Multics ran on Honeywell 6180 and DPS8/M machines. They had 36 bit words like the PDP-10. They also had instructions that would operate o in 6 or 9 bit characters in the word

The VAX had byte addressable memory, the DPS8/M word 36 bit word addressable, so I suspect that byte oriented instructions might have an edge on the VAX. Contrawise, the DPS8/M memory bus width was 72 bits, so it might have had an edge in double wide operations. I suspect the dominate factor would be that the DPS8/M was core memory at 1 us access time; I don't know the memory bandwidth of the VAX but I would assume it was faster.

According to wikipedia, the 6000s ran about 1 MIP and the DPS8/Ms topped out about 1.7 MIPS. Talking with people that worked on Multics, they generally say the 6000s were about 1 MIP.

Multics achieved security by building it into the h/w. That caused the h/w to be more expensive and slower. The system market these days is all about price/performance ratio and the collective decision not to include security as a performance metric.

IIRC,Primos was written in FORTRAN (with language extensions including the ability to pass a statement number as a parameter, allowing longjmp() like behavior).

Multics (as noted above) was written in PL/I.

Multics: Security.

Non-single level stores are copy-on-demand. Typically, a process runs a program by starting with an empty address space and mapping the executable code into that space. The program is started, the first instruction fetched; the address space is empty a page fault occurs and the page is copied in. If the page is modified, that is local to the process and the disk image is unchanged. Each process has its own copy of writable pages.

With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.

An FPGA implementation is underway.

The X86 segmentation facility resembles Multics segments in name only.

Run your own Multics:

https://multics-wiki.swenson.org/index.php/Main_Page

There are also several public access Multics systems up and running.

The Burroughs system for the B5000 was written in Algol and preceded Multics.

Multics is written almost entirely in PL/I, plus some assembly for bootup, some messy low level stuff, and time critical bits like process switching.

Many additional languages are available, such as COBOL, FOTRAN, APL, BASIC, Assembler, JOVIAL and others I can't recall off the top of my head.

Multics was co-developed with the hardware; that hardware contains Multics specific features that are needed to implement Multics. Segment tables, Rings, Gates and more. enable the memory mapping and protection that that is the basis of Multics.

These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.

The website will be back online soon; the system can be accessed ssh dps8@m.trnsz.com

https://multicians.org/mgs.html#segment

segment User-visible subdivision of a process's address space, mapped onto a storage system file. Each segment is 1MB long, and has a zero address. The term "segment" is used interchangeably with "file" -- except not really: the things that are files in other systems are implemented as segments; also, the term "file" includes multi-segment files, and when talking in terms of COBOL, PL/I, or FORTRAN language runtime objects, one speaks of files. Programs are spoken of as stored in (procedure) segments. Correct use of the terms "file" and "segment" is a sure sign of a Multician.

But oddly, in Multics they became "ec" (execute command maybe?).

r 13:41 0.055 7

ls >sc1>system_start_up.ec

Segments = 1, Lengths = 2.

r w 2 system_start_up.ec

http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AN5...

Porting is unfeasible; Multics relies on hardware features not available. An emulator for the original hardware can be found at: http://ringzero.wikidot.com/ Information about Multics at: https://multicians.org/

I would argue that Multics security was due more to the ring and gate hardware architecture, that security was designed into the software from day 0 (rather then being grafted in afterwards), and code review practices.

Reading the Multics B2 security analysis reveals that the review team did find security holes in Multics which were fixed as part of the review process.

Recently, a buffer overflow vulnerability was found in the Multics CKermit implementation, despite it's being written in PL/I.

Security is hard, and is achieved through good programming, not by (just) trusting tools.

Getting multiple CPUs running has been quite an adventure.

PL/I doesn't prevent memory access bugs, but it makes it easier to do good programming. For example, parameters are passed by descriptor, so the allocated size is passed allowing run-time bounds checking. On the other hand, there is an equivalent of C type-casting, so it is still possible for the programmer to shoot themselves in foot while simultaneously hoisting themselves on their on petard.

And two systems to the NSA.

A writeup is on my round tuit list; some day soon.

PL/I does bounds checking on arrays, but not on pointers.

The Kermit server allocated an insufficiently large buffer to decompress packets into, and used ptrs to write to the buffer. (Errors 1 and 2: allocation and ptrs)

Later in the code, there is a 'goto state(idx)' construct, with a declaration like 'dcl state (0:6) label init (state0, state1, ....);'.

Which label is jumped to depends on the value of idx.

The 'state' variable was not declared to be state (error 3), so the table is in writable memory, and due to whatever circumstances, is above the decompress buffer.

A correctly crafted packet, when decompressed, will write over the end of the buffer and onto the state array. Later, when the goto is executed, the address transferred has been changed. It is not the case that a transfer can be made into the decompress buffer, as it is not in an executable segment, there are lots of places that could be transferred to, leaving open the possibility of an exploit.

The error was discovered when a particular file transfer would reliably crash the kermit server, and analysis of the crash uncovered the coding errors.

Sadly, a buffer overflow attack has been found; it is possible to write bad PL/I. (The defective code is a user-space tool, so at best, a remote code exploit. No privilege escalation.)

The bulk of Multics is written in PL/I.

See https://multicians.org/pl1.html for details.