Does the Intel 8086 CPU have user mode and kernel mode as modern CPUs do? and if it doesn't have user mode and kernel mode, does that mean that any user program written for the Intel 8086 CPU could do anything that the OS can do?
5 Answers
No. There is no mechanism for any privilege levels or protection in 8086. As a consequence, there is nothing special about OS code, and thus user applications are allowed to do everything, including reading and writing to any physical memory address, directly access any I/O port, and enable/disable interrupts at will.
Protected mode was introduced in 80286. Some non-PC compatible systems with 8086/8088 might have had external hardware that was used to provide protection and distinction between kernel and userland code, but I haven’t found really good sources for those, so I can’t tell how it worked.
-
1IIRC, the only hardware “security” provided by external hardware was in the form of dongles, preventing use of the hardware and associated software without it — in other words, anti-theft for software/hardware. The PC itself could not be secured by software alone. Commented Jul 27, 2019 at 4:39
-
3@Dúthomhas, there's some discussion about 8086 systems with external hardware for memory protection under this question: Can one isolate processes on a 8086?– ilkkachuCommented Jul 27, 2019 at 7:33
-
4@ilkkachu Altos shipped machines with 8086 processors, their own MMU and which had full memory protection. Even before that other companies had done it with extra glue and processors like the Z80. In the Altos case they ran Xenix.– Alan CoxCommented Jul 27, 2019 at 22:53
-
3Note that 386 protected mode != 286 protected mode; it adding virtual paging which 286 protected mode didn't have and has different IDT / GDT entry layouts.. So the mode that modern 32-bit x86 OSes still use was added in 386, with a more primitive version of it added in 286 that used some of the same basic ideas like segments as descriptor indexes instead of as offsets themselves. Commented Jul 28, 2019 at 21:55
To answer the second part of the question, yes, any program could do what the OS could do. Some of the useful reasons included:
Directly access hardware, especially to provide support for third-party expansion cards.
Directly access graphics memory, to draw graphics.
Overwrite system calls, to alter or extend the functionality of the OS. Certain TSR programs that did this were especially popular.
answered Jul 26, 2019 at 15:01
Does the Intel 8086 CPU have user mode and kernel mode…
No
…as modern CPUs do?
I guess you mean "modern" x86 CPUs, the offspring of the 8086, right? Alas, the idea of an ISA with privilege levels is way older than the 8086.
and if it doesn't have user mode and kernel mode, does that mean that any user program written for the Intel 8086 CPU could do anything that the OS can do?
Yes.
And that's what brought us the mess of direct screen addressing, user I/O, mangling with interrupts, and so on. These things made life hard for any proper OS to offer compatibility with DOS programs—at least until CPUs got fast enough to just emulate everything.
answered Jul 26, 2019 at 21:42
The 8086 has no programmer-visible supervisor/user model in the instruction set architecture.
However, it exposes a lot of state information through its pins, such as pins S0, S1 and S2 that interface to a bus controller (like the Intel 8288).
The S0, S1 and S2 pins indicate what kind of access the 8086 is making: code, data, I/O and so on. Together with the address pins, you can get an idea of what the CPU is doing: in what area of memory is it executing code and what it's trying to access.
It seems very promising, therefore, that a supervisor/user-like protection scheme is possible if we control the board design. We could design a piece of hardware (to augment or replace the bus controller) which decodes the processor state from the S1-S2 pins, address pins and perhaps others, and acts as a gatekeeper to the external bus, preventing accesses to certain areas by unprivileged code. That piece of hardware could itself be programmable in various ways, and only by kernel code. It could be told to reveal certain address ranges, or close off access. It could deliver an external interrupt to the processor if it attempts an illegal access.
-
Yeah, you could theoretically do it, but if you're going to spend the money and effort, why not buy a CPU that already has it? The 68000 (or better, the 68010) was certainly contemporary to the 8086, and had a supervisor mode. Commented Jul 27, 2019 at 3:27
-
@Kaz We had something similar on our Z80-based POS terminals - an attempt to write to certain address ranges would trigger a reset, thus preventing the code corruption and eliminating the need to reload the software each time you hit a bug.– tum_Commented Jul 27, 2019 at 7:36
-
1@DrSheldon It could not only be done, it has been done. Like with some Multibus CPU boards for Unix.– RaffzahnCommented Jul 27, 2019 at 8:04
-
1@DrSheldon If you're going to do anything today, you get an ARM Cortex M3 or whatever. :) The purpose of this answer is to reveal that there are external interfaces on the 8086 device which can make security zoning possible, not to argue that it's economic.– KazCommented Jul 27, 2019 at 16:54
-
1
No, the original 8086 only has real mode, which is maintained in all later x86 CPUs. In this mode, memory is only accessible using physical addresses, although it's still not exactly a flat address space because of segmentation.
-
In real mode, segment registers are just used directly as segment bases (
linear = (seg << 4) + offset), not as indices into a table (GDT / LDT) of segment base/limit. So a program can always figure out the linear address of a seg:off pair. Like you say, real mode isn't even trying to do any abstraction, but programs and the OS can agree on how they will use segments. Commented Jul 28, 2019 at 21:59
s/as modern CPUs/as 1960's mainframes/