Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!chinacat!chip From: chip@chinacat.Unicom.COM (Chip Rosenthal) Newsgroups: comp.unix.sysv386 Subject: Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386 Keywords: BAD BUG Message-ID: <1872@chinacat.Unicom.COM> Date: 20 Feb 91 23:52:57 GMT References: <3227@sixhub.UUCP> <1991Feb18.175533.12275@kithrup.COM> <1991Feb20.005322.24769@scuzzy.in-berlin.de> Organization: Unicom Systems Development, Austin, TX Lines: 22 In article <1991Feb20.005322.24769@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >well, HOW did they [SCO] fix it??? By looking at , it looks like they used the AT&T 3.2.1 approach. The fp registers appear at the very top of the structure, along with kstack. Therefore, this page could be mapped into user space, leaving the second page with the sensitive stuff untouchable. What I'm really curious about is how XENIX does it. The fp emulation is done in the kernel, but it does not appear that XENIX maps any portion of the user structure into user space. I think I've found the address at which user is placed, but any attempt to access it dumps core. I'm wondering if the working registers for the fp emulator are maintained elsewhere, and moved into/out of the user structure when a process is scheduled/unscheduled, just as the hardware coprocessor registers are. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. |