Weitek under unix (was Re: SECURITY BUG)

James Van Artsdalen james at bigtex.cactus.org
Wed Feb 13 02:11:19 AEST 1991


In <1991Feb12.020625.6779 at kithrup.COM>, sef at kithrup.COM
	(Sean Eric Fagan) wrote:

> In article <1991Feb11.184130.11321 at jwt.UUCP> john at jwt.UUCP
	(John Temples) writes:

| Yikes.  This also works on ESIX-D without a coprocessor, and on ISC
| 2.0.2 *with* a coprocessor.  It failed on Microport 2.2 with a
| coprocessor.  Now, the question is, what do we do to protect ourselves
| in the meantime?

] Get SCO.  It does not have this "feature," and still manages to
] support Weitek coprocessors (the coprocessor the original poster was
] referring to, I believe).  (The Weitek's use memory for registers and,
] obviously, need to be able to write them.

The Abacus (Weitek is the company name) does not use memory for
registers, but instead uses memory for the instruction set.  There is
no one memory location where one can both read and write an Abacus
register: instead, there is a location that corresponds to a "load
register N from data bus" and a different location that corresponds to
"write register N to data bus".  "N" is encoded in the memory address.

The base address for the Abacus under unix is 0xffc00000.

] The weitek registers are stuck in the upage, and happen, in
] apparantly every 3.2 save SCO's, to be in the same page as the uid
] stuff.  *Bad*.  *Very* bad.)

There is no reason a user application should ever need to write to the
Abacus registers in the u block, no more than an application ever
needs to write to the copy of the 386 registers in the u block.
-- 
James R. Van Artsdalen          james at bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789



More information about the Comp.unix.sysv386 mailing list