supervisor mode on 8086

[[e-mail]]

Is there any reason why some sort of supervisor
mode and memory protection couldn't have been
added to the 8086, perhaps producing an 8086+?

I think 2 things are required:

1. The ability to restrict applications to only being
able to do INT 21H, or perhaps a handful of others.
Other interrupts are OS-reserved.

2. A "low-water" mark, where applications are not able
to write below a particular address, which will be set
by the OS to protect itself.

I don't care that applications will still be able to trash
each other.

Maybe an 8086+ could be created in Bochs.

Thanks. Paul.

[Alexei A. Frounze]

Post by ***@gmail.com
Is there any reason why some sort of supervisor
mode and memory protection couldn't have been
added to the 8086, perhaps producing an 8086+?

As usual, complexity, cost, time?
Also, probably it wasn't quite the time for every general purpose
CPU to offer protection? Because of limited spread and use
of computers and there not being the internet like today.

Post by ***@gmail.com
1. The ability to restrict applications to only being
able to do INT 21H, or perhaps a handful of others.
Other interrupts are OS-reserved.

Ports need to be restricted.

FLAGS.IF (Windows 9x could be locked by a 3-byte .COM program
that would disable interrupts and loop forever).

The stack must be switched on user<->super transitions to make
sure the OS can survive stack overflow on the user side.

The OS need to restrict file access and other resources on
top of memory and CPU.

Post by ***@gmail.com
2. A "low-water" mark, where applications are not able
to write below a particular address, which will be set
by the OS to protect itself.
I don't care that applications will still be able to trash
each other.
Maybe an 8086+ could be created in Bochs.

Sure.

Alex

[[e-mail]]

Post by Alexei A. Frounze

Post by ***@gmail.com
1. The ability to restrict applications to only being
able to do INT 21H, or perhaps a handful of others.
Other interrupts are OS-reserved.

Ports need to be restricted.
FLAGS.IF (Windows 9x could be locked by a 3-byte .COM program
that would disable interrupts and loop forever).

Thanks.

Post by Alexei A. Frounze
The stack must be switched on user<->super transitions to make
sure the OS can survive stack overflow on the user side.

Ok, but that does not require a hardware change, right?

Post by Alexei A. Frounze
The OS need to restrict file access and other resources on
top of memory and CPU.

Sure, no hardware change required there either.

Post by Alexei A. Frounze

Post by ***@gmail.com
2. A "low-water" mark, where applications are not able
to write below a particular address, which will be set
by the OS to protect itself.
I don't care that applications will still be able to trash
each other.
Maybe an 8086+ could be created in Bochs.

Sure.

Does a V86 basically create the same thing as an 8086+?

My OS needs to switch to real mode to do BIOS interrupts,
but if I start running user apps too, it would be good to
have either real mode restricted as per 8086+ or some
alternative.

If my MSDOS app does a BIOS call, I don't care if it dies,
but if it does an INT 21H to request an OS service, I would
like it to transition back to normal protected mode where
my OS is so that the request can be serviced.

Eventually, anyway. At the moment I don't really care if
an MSDOS program does "unauthorized" calls, I just
want it to work. Actually, I don't even need MSDOS
programs to work, just huge memory model programs
that request OS services via the method I outlined.

But eventually it would be cool to support actual
MSDOS programs, and restrict them to user mode.
But with minimal changes to my OS compared to
doing the same thing in real mode (ie allowing them
to run in (effectively) supervisor mode).

BFN. Paul.

[Alexei A. Frounze]

Post by ***@gmail.com

Post by Alexei A. Frounze

Post by ***@gmail.com
1. The ability to restrict applications to only being
able to do INT 21H, or perhaps a handful of others.
Other interrupts are OS-reserved.

Ports need to be restricted.
FLAGS.IF (Windows 9x could be locked by a 3-byte .COM program
that would disable interrupts and loop forever).

Thanks.

Post by Alexei A. Frounze
The stack must be switched on user<->super transitions to make
sure the OS can survive stack overflow on the user side.

Ok, but that does not require a hardware change, right?

Post by Alexei A. Frounze
The OS need to restrict file access and other resources on
top of memory and CPU.

Sure, no hardware change required there either.

At the very least your timer ISR that drives the scheduler
must be careful not to try to save any OS state on the stack
on the entry path before it sets up usable SS:SP. 'cause if
SS:SP points to a memory hole or ROM, there will be no way
to restore anything. Also, the holes should simply ignore
reads and writes without any adverse effects as is often the
case in modern PCs.

Also, if it's not a 8086-based, you're risking an exception on
misaligned stack (e.g. when SP=1) when taking an interrupt.

I'd rather have hardware stack switching.

Post by ***@gmail.com

Post by Alexei A. Frounze

Post by ***@gmail.com
2. A "low-water" mark, where applications are not able
to write below a particular address, which will be set
by the OS to protect itself.
I don't care that applications will still be able to trash
each other.
Maybe an 8086+ could be created in Bochs.

Sure.

Does a V86 basically create the same thing as an 8086+?

Basically, yes. But, not entirely and not without any effort on your side.

Alex

[wolfgang kern]

Post by ***@gmail.com
Is there any reason why some sort of supervisor
mode and memory protection couldn't have been
added to the 8086, perhaps producing an 8086+?

as Alexei already said there were no need at this time (40 years ago).

Post by ***@gmail.com
1. The ability to restrict applications to only being
able to do INT 21H, or perhaps a handful of others.
Other interrupts are OS-reserved.

even not at all recommendable you could create an IDT where everything
except your desired int21 is either ignored (by IRET) or invoke an OS
controlled trap. BUT HW-IRQs will then sure not be satisfied in time.

Post by ***@gmail.com
2. A "low-water" mark, where applications are not able
to write below a particular address, which will be set
by the OS to protect itself.

CS, DS and SS were made for that, but cannot be write protected.
IIRC some other old MCUs already had an address limit opportunity.
__
wolfgang