Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!sdd.hp.com!wuarchive!csus.edu!beach.csulb.edu!nic.csu.net!csun!kithrup!sef
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.unix.sysv386
Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386
Keywords: BAD BUG
Message-ID: <1991Feb18.175533.12275@kithrup.COM>
Date: 18 Feb 91 17:55:33 GMT
References: <3215@sixhub.UUCP> <1991Feb18.042427.9434@kithrup.COM> <3227@sixhub.UUCP>
Organization: Kithrup Enterprises, Ltd.
Lines: 43

In article <3227@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>  My understanding is that the emulator is keeping the fake registers
>in the user area, and mapping that into addressable user space. 

Well, in that sense, your understanding is wrong.  Actually, it's just
limited.  Lots of small parts of your posting were wrong; so I think you've
just got a wrong picture of the entire thing.

First of all, the emulator is only using the registers that the kernel would
have saved for context switches; why bother using another 70 bytes?

As for using high stack space, keep in mind that the emulator is *not* part
of the kernel, it is *not* part of "system services."  How do you propose
the emulator find out where 'high stack space' is?  I believe stack start is
dependent on data end, isn't it?  And the emulator has no idea what the
process' structure looks like.

>  Again, I may be missing something, but the solution seems pretty
>simple. Disable the mapping of the user block into user space, then have
>the emulator allocate memory, use high stack, or otherwise look in a
>more sensible place. I'd bet that there's one pointer to the user block
>structure, and that changing the logic which initializes it would
>suffice.

Where would you put the user block?  It has to go *somewhere*.  Where is
high stack?  Where is data begin?  How about code begin?  How about data
end?  Or code end?  Or bss end/begin?

Tell you what, bill.  You can write a new emulator that lives in kernel
space.  That will make you much happier, I bet.  It will also slow down
systems without fpus by a considerable margin (the context switch times
would go up *enormously*).

SCO managed to get it working before their first release; AT&T and Dell
managed to get it "fixed" for their second release.  All without having to
redesign an enormous program written entirely in assembly.  Or would you
rather that the fpu emulator have more bugs introduced?

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.