History, reason for and implications of the 2 modes of a modern microprocessor?

Question

The modern microprocessors I've dealt with could have 2 modes: User and superuser (and sometimes this difference was just in the manual and not actually implemented like with the Nios II which states that it has 2 modes but only implements 1). Therefore I wonder if this is true in general about microprocessors i.e. it is not very advantageous to add more modes than 2 for instance a third mode that could be "supersuperuser" (which in practice could be that a "supersuperuser" could change the privileges of "superusers") if there could be need for 3 modes? And is it this mode difference of the CPU in modern systems that has caused the design difference between operating systems where some operating systems are called "microkernels" because of their way to load device driver programs in user mode instead of in superuser mode, which is the way of a monolithic os kernel? What is the history about the 2 CPU modes getting developed? It says in another SE comment:

I saw the names "user mode" and "supervisor mode" in ARM2 first (late 1980's),

So the early microprocessors like Intel 8080 and Zilog Z80 didn't have modes so any program that was run could run any instruction?

https://superuser.com/questions/634733/why-so-many-modes-are-in-cpu

Are these 2 modes usually implemented in hardware and if so, what does the implementation look like? What is it that changes when a microprocessor switches modes between user and superuser?

Answer 1

Rather a lot of questions in this question, but I can address some of them.

Intel have four modes known as "rings", but two are frequently unused.

Intel 8080 and Zilog Z80 didn't have modes so any program that was run could run any instruction?

Correct. The privilege separation technique had been invented, but the complexity cost of adding it to microprocessors was large and those processors were used in single-user, single-process systems with no networking. Security simply wasn't a consideration.

What it "looks like" depends on where you're looking from. The programmer's guide for ARM shows the programmer's view for that architecture. The electrical implementation may vary - whether the registers are physically swapped out or just renamed.

It's necessarily implemented in hardware so that it cannot be circumvented.

Answer 2

The history of this started with timesharing, and the purpose was to isolate user processes from each other.

When there is more than one independent user on a machine, it is to each user's advantage to take as much of the resources of the machine as possible while leaving the others with nothing. Without some kind of hardware protection, once a user got the CPU he could keep it forever.

This was dealt with by having different modes, sometimes called rings or privelege levels. User processes run at the lowest privelege and can not physically take over the machine. This works in conjunction with protections for areas of memory also based on the privilege level.

In the most basic form, you only need two privilege levels: user and OS. Historically there have been machines that had more. Four seemed to be a popular number for a while. However, operating systems rarely made much use of more than two privelege levels.

Microcontrollers and early microporocessors don't have privelege levels because they are not intended for applications with hostile competing processes.

Answer 3

Almost everything that can be done by having a CPU distinguish supervisor/user mode distinctions can be accomplished with a memory management unit which is external to the CPU and controlled as an I/O device, but there are a few caveats:

-1- In general, it is not desirable for user-mode programs to have the ability to disable interrupts, but if user code performs a "disable interrupts" instruction it may be difficult for an external MMU to do anything about it. An MMU could snoop the bus and trigger an NMI if it sees user-mode code fetching a "disable interrupts" instruction, but it would be easier to have the CPU block the instruction itself.

-2- Interrupts need to be able to do things which user-mode can't, which implies that when an interrupt is taken the MMU needs to switch out of "restricted user" mode. A unit which watches what's going on may be able to do this, but it's more easily handled in the CPU.

-3- User mode shouldn't be able to corrupt the stack used by interrupts. It's possible for interrupt handlers to take care of this even when using an external MMU with a processor that knows nothing about user/supervisor modes, but it's a lot more efficient to have a processor which can switch stack pointers internally.

While there can be advantages to having more modes than just user/supervisor, it's often not worth the added complexity. The hardware for a two-level system is simpler than the hardware necessary to work around its absence, but adding more levels complicates hardware rather than simplifying it. Further, having software emulate more levels on top of a two-level hardware system may be easier than performing such emulation when using multiple hardware levels.

PS--while it's bad for user-mode tasks to be able to disable interrupts for arbitrary periods, I've often wished for processors to include a "temporary interrupt disable" counter, and include an instruction which would disable interrupts temporarily (e.g. for the next 8 instructions or so); if the instruction was executed again within the next 8 instructions and an interrupt had become pending, the interrupt would be immediately, and on return the instruction would execute again. Such a feature would greatly ease the writing of interrupt-safe data structures on single-processor machines.

Answer 4

Microprocessors are simply and no more than a collection of binary switches. There can be paths pre-connected among the switches that work similar to computer programs, but these connected paths do not change the fact that microprocessor are only a collection of binary switches.

The "2 modes: User and superuser" that you spoke of are either hard-connections on the cpu or connections elsewhere.

Having said that; If these pre-connections exist on a microprocessor then they can dictate how commands from programs (being simply and no more than binary) are run through the collection of binary switches. For example: in superuser mode more paths might be allowed to be completed than in user mode. For this to happen, a manufacturer of the microprocessor might have some blocks to the resulting binary logic circuit's result return if the binary switch that allows superuser to be ongoing is turned off (in user mode). Another way of looking at this is that the default from the manufacturer could be superuser, whereas the operating system instigates a block switch to be turned on (for user mode) by default until the operating system is told to not block superuser logic returns.