james@bigtex.cactus.org (James Van Artsdalen) (02/12/91)
In <1991Feb12.020625.6779@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) wrote: > In article <1991Feb11.184130.11321@jwt.UUCP> john@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@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
rfarris@rfengr.com (Rick Farris) (02/13/91)
In article <54428@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: > The Abacus (Weitek is the company name) does not use memory for > registers, but instead uses memory for the instruction set. > There is no reason a user application should ever need to write to the > Abacus registers in the u block So James, I'm having trouble reading through the obfuscation -- I really don't see what the facts above have to do with the subject of whether or not Dell Unix has the bug. Here, here's a simple yes or no question: "Does Dell Unix allow user processes to overwrite the u block?" (You *did* have to jump into this, didn't you?) :-) -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
james@bigtex.cactus.org (James Van Artsdalen) (02/16/91)
In <1991Feb13.050417.10170@rfengr.com>, rfarris@rfengr.com (Rick Farris) wrote: > In article <54428@bigtex.cactus.org> I (James Van Artsdalen) wrote: | The Abacus (Weitek is the company name) does not use memory for | registers, but instead uses memory for the instruction set. > So James, I'm having trouble reading through the obfuscation -- I > really don't see what the facts above have to do with the subject of > whether or not Dell Unix has the bug. The Subject: was "Re: Weitek under unix (was Re: SECURITY BUG)". The contents corrected misimpressions on how the Weitek worked. The Weitek does not need the u block to be writable, and there is no reason for 387 support (real or emulated) to need the u block to be writable. > Here, here's a simple yes or no question: "Does Dell Unix allow user > processes to overwrite the u block?" It does not allow it on my 486. I have no 386 to try it on. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
sef@kithrup.COM (Sean Eric Fagan) (02/16/91)
In article <54602@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >there is no >reason for 387 support (real or emulated) to need the u block to be >writable. Yes, there is, unless you want to make the emulated fpu even slower. Currently, the fp emulator runs in ring 3, just like user processes. When you try to execute an fp instruction (and don't have an fpu), after some inital setting up, you go directly from your process (in ring 3) to the fp emulator (also in ring three). This is *tons* faster than going to another ring. Since you might have hundreds of fp instructions, an additional 60+ clocks for each emulated instruction *would* be noticeable. >> Here, here's a simple yes or no question: "Does Dell Unix allow user >> processes to overwrite the u block?" >It does not allow it on my 486. I have no 386 to try it on. Try booting with 'ignorefpu' (I think that's the option). That will tell the kernel to run the fp emulator anyway. -- 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.