denton.burr
New Member
I am talking VM systems or multiprogramming systems that supported process isolation (base address register plus address limitation register) and segregated privilege and non-privileged address spaces.
My favorite is not on a vintage computer but the old SPARC v7 computers running SunOS 4.1.1.B. On that computer an unsigned divide instruction could make you root. I kid you not.
In the SPARC some instructions were not part of the implementation but the architecture. That is some machine instructions where not done in hardware but were emulated.
The whole thing was that unsigned divides (among other instructions) were not implemented in hardware but were instead done via a hardware trap that dispatched a software routine that emulated the machine instruction. In the compilers for the SPARC, the languages used a ".udiv" subroutine call to do this without the expense of the hardware trap (that is user-level code emulated the instruction in userspace).
The error was in the kernel software routine (trap handler). The kernel code TRUSTED a user-level stack pointer (it is not a privilege instruction to change the stack pointer).
SunOS did not have a separate instruction address space for the kernel but one that was mapped into every process at a very high address albeit write protected. So the user was able to set the stack pointer to the ublock (really u_ptr or pointer to ublock) and change the uid to zero by taking the stack pointer in the local register window (a local register) and do an unsigned divided of zero by an non-zero integer and store the results at the offset in the user page (ublock) that was located at the effective uid, effective making it zero or root.
Basically, bozo error on a trap handler for an unimplemented instruction that was part of the architecture but not the implementation.
Best Regards.
Denton
My favorite is not on a vintage computer but the old SPARC v7 computers running SunOS 4.1.1.B. On that computer an unsigned divide instruction could make you root. I kid you not.
In the SPARC some instructions were not part of the implementation but the architecture. That is some machine instructions where not done in hardware but were emulated.
The whole thing was that unsigned divides (among other instructions) were not implemented in hardware but were instead done via a hardware trap that dispatched a software routine that emulated the machine instruction. In the compilers for the SPARC, the languages used a ".udiv" subroutine call to do this without the expense of the hardware trap (that is user-level code emulated the instruction in userspace).
The error was in the kernel software routine (trap handler). The kernel code TRUSTED a user-level stack pointer (it is not a privilege instruction to change the stack pointer).
SunOS did not have a separate instruction address space for the kernel but one that was mapped into every process at a very high address albeit write protected. So the user was able to set the stack pointer to the ublock (really u_ptr or pointer to ublock) and change the uid to zero by taking the stack pointer in the local register window (a local register) and do an unsigned divided of zero by an non-zero integer and store the results at the offset in the user page (ublock) that was located at the effective uid, effective making it zero or root.
Basically, bozo error on a trap handler for an unimplemented instruction that was part of the architecture but not the implementation.
Best Regards.
Denton