I am trying to design a 6809E based system, and would like to implement a unix-style r/w + x memory protection. The datasheet for the 6829 MMU describes how to do read/write protection, but not execution protection. I’d like to extend its system. The way the datasheet describes it is where the upper line of the MMU decoded addr bus is latched to the r/w signal. My best idea so far is to use the LIC signal to determine when an instruction is being fetched, and then use some TTL logic to decode that, and latch it to another one of the MMU lines.
The datasheet describes is a lot better than I can: http://matthieu.benoit.free.fr/cross/data_sheets/mc6829.pdf
That sounds like a promising approach! It may also be a lot of work, though. My instinct is that you won’t be able to use a 6829 to manage both data and instruction memory; you might need a second MMU for instruction access. (I haven’t read the data sheet carefully, though.)
Note that execution protection was not very typical on early Unix systems; it was provided almost by accident in a not-very-effective way on the later models of PDP-11, as their MMU mapped instruction and data space separately; instruction memory was only accessible when accessing memory using the PC as an indirect register or relative offset.
Execution protection as a way of life really didn’t come about until some time around 2000; it seems likely that big iron systems had it earlier than desktop systems, but x86 didn’t get it at all until AMD introduced AMD64. Wikipedia claims that it was added to various other platforms in the early 1990s (e.g., ARMv6 and SPARC v8). I’m not sure if POWER had it from the beginning, but my 2000 PowerPC manual includes NX permissions.
Either way it’s a very interesting problem, and I’ll be interested to hear how you solve it!
The idea is to use the upper two decoded memory lines for the r/w and x controls. I hope I can do that with one, but I’ll have to see.
The relevant part of the datasheet:
MEMORY PROTECTION - The MMU can provide
memory protection on a per page basis by defining the high
order physical address line (PA20) as a write access line. If
write protection is desired, this. signal can be gated with the
read/write line, from the processor, to generate a disable
signal. This can be used to inhibit the memory chip select
logic or generate an interrupt to signal a violation of a write
protected area. The write protect line can also be combined
with the DMA/VMA logic that is necessary in systems using
DMA. In this case, writes to protected memory would appear
as dead cycles to the main memory. Note that the
designtion of the write protect line is purely arbitrary. The
MMU simply combines the incoming address with the current
task number to determine a 10-bit result. If no write protection
is needed, PA20 can be used as a 21st address line,
giving a total addressing range of 2 Megabyte. This scheme
can be reversed if desired and additional output lines from
the MMU can be used to specify more attributes of the
physical pages at the expense of reducing the number of
pages in physical memory.
I did not know that, about the exec protection. I am used to the memory map of modern Linux systems, and kinda assumed it had been that way for a very long time. That’s very interesting.
Execution protection was added to the x86 in in the 286 protected mode, which borrowed from the iAPX432. The operating system I wrote in 1988 for that processor certainly made use of that. Normally the same segment would get two different descriptors to it: one available to the application that only allowed execution and another for the system that allowed reads and writes (but not execution). Otherwise the protection would keep you from loading the program from a file in the first place.
Oh; that’s certainly true! It was lost again with 386 protected mode, though, and did not reappear until AMD64. All x86 processors since the 286 have supported it in segmented mode, however. Segmented mode was, ironically, dropped with AMD64; I would have to check the documentation to see if modern processors still support it at all (they probably do), but the only mapping available to 64-bit instructions is via page tables.