8086 memory space was: The Soul of Barb's New Machine 1160

No, tops20 had protection on individual pages, and the loader set them right. The instructions for that is in the .exe file.

Malignant code, either by purpose or my accident.

If you want to mess with things, you tell the computer to turn on your mess permissions first, or it traps.

On tops20 this was implemented. You saw the permissions on up to today's standards, but the hooks were there. ISTR there were linker options for setting code execute-only; but that there was too much self-modifying code around for it to be turned on as a default.

Only code segment pages should have the execute permission bit on; and NO write permission. Data is divided into two, pure(e.g. literals and constants) and impure (e.g. variables). Pure had read permission, and impure RW permission. The stack has RW, with a non-accessible page at each end to stop under and overflows. Linkage wasn't there in tops20. Self-modyfying code will trap on such a system.

(Linkage is when you call a dynamic library. This is done through an impure code segment with a little bit of stub code; normally just an indirect reference. When you call it the first time it isn't filled in. It traps, the linker finds the relevany library, maps it into user space, initializes it, and writes the address into the caller's linkage segment. To do this safely it has to modify permissions on this linkage segment on the fly. Likewise does a debugger have to handle access to the code segemnt of the subprocess if you were to patch the code. )

An .EXEnot the msdos-windows format file is just a wrapper around code and data segments. It has a direct follower in the elf file, except the elf format has developed somewhat further; and supports things like pure and impure data, linkage, and have much larger tables for things.

The compiler and linker have a fair idea about what is code and what is data, because you told them in your program.

You don't have to do a rebuild to change access to the program. This is about hardware enforcing what the program superficially says it does. Just like subscript checking. If you address element number 12 of foo(10) the program should fault. If you write to the string "constant" it should also fault. If you try to execute the stack it should fault.

Now, you may WANT to do something like execute "...... 8086 code here"; but then you must turn on execute permissions to that string first.

If you want to examine the elf file there are lots of tools for this. You don't have to do a rebuild.

If I want to revoke access to the file i give a shell command.

It is a different set of permissions (well, not in Multics, there they are an integrated set). It is about access to the segments INSIDE the exe.

It is a different world now.

And it is exposed to rigours of formality noone would have dreamt of in 1985; and code is extensively reviewed if it ends up in the kernel or core libraries. And the coders are pros, make no errors in that.

Could you imagine what it would have been like if you had to submit the source changes in Tops10 to peer review, with IBM, HP and SGI among the peers? This is what it is like now.

IBM, SGI, RedHat and HP pore over everything that goes into Linux. What is different now is that is has been moved out into the open, and is auditable. The Linux team can actually present the history of every line of code in the whole system; and so can most of the BSD distributions.

The fact that two so divergent codebases (linux-gnu and the BSDs) can coexist so well is that it is exposed to these rigours.

ld.so should have been made part of the kernel; it is a great example of something that would fit right into ring 1.

But we are not there yet.

-- mrr