C bug causes double fault

[Dick Dunn]

In article <9900 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <27245 at cci632.UUCP> tvf at ccird7.UUCP (Tom Frauenhofer) writes:
> >On Microport V/AT, what he wrote causes a kernel panic.  That doesn't seem
> >to be reasonable behavior for an OS/library routine/whatever.
> 
> Of course nobody would call it "reasonable", but it's not too surprising.
> Incorrect user-mode code on a nonprotected multitasking system (forced by
> limitations of the PC/AT architecture) can easily crash the entire system.

What, more specifically, are the "limitations of the PC/AT architecture"?

Microport runs the 286 in protected mode.  Each process has its own memory,
protected via the LDT, and the GDT entries <should> be set so that user-
level code can't get outside its playpen.  The memory protection in the 286
is a fairly serious nuisance to work with, but it is there.

Exceptions occurring in user mode go through a call gate into system mode
where you can straighten out the mess.  You change stacks when you change
privilege levels; in the kernel you're in an environment as safe (and as
insulated from user-code screwups) as you care to make it.

Is there some problem with the 287 interaction with the 286 in protected
mode that can't be made safe?  Specifically, what can a user-mode program
on the AT do, when running in protected mode, that the OS couldn't protect
against?
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Never offend with style when you can offend with substance.