SECURITY BUG IN INTERACTIVE UNIX SYSV386

[Steve Nuchia]

In <1991Feb16.214824.2790 at kithrup.COM> sef at kithrup.COM (Sean Eric Fagan) writes:
>any lower ring sometime; it's disgusting.)  Since it runs in the same ring
>as your process, it looks just like it is part of your process (i.e., if
>you're using the emulator, you seem to have a multi-segment process).  Since
>it needs to keep the fp registers somewhere, and they are very much
>process-related, the "proper" place to keep them is in the u area, just like
>other registers.

Unmitigated bullshit.

The decision to have the emulator store its variables in the u-area
was simple laziness.  The decision to leave it there after it was
realized that it was a security hole was *negligent* laziness.

The only technical justification for putting them there are
	1) so they get initialized at startup without additional
		code in exec.
	2) to avoid having to allocate a chunk of data space and
		figure out how to address it from the emulator.

A third possibility would be a multiprocessor box where a process
might migrate between CPUs with and without coprocessors.  Or
maybe so you can hot-plug the fool things.  Having the emulator
keep its variables in the same place as the coprocessor does
(when the process is asleep) would make these work.

None of these are any where near strong enough to make a sane person
think for a moment that leaving u writable is justified.

Feh.
-- 
Steve Nuchia	      South Coast Computing Services      (713) 964-2462
	"Innocence is a splendid thing, only it has the misfortune
	 not to keep very well and to be easily misled."
	    --- Immanuel Kant,  Groundwork of the Metaphysic of Morals