From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 12 Feb 1999 13:34:00 -0800 (PST)

Re: STB and S3 tech specs

On Thu, 11 Feb 1999, Mike McQuade wrote:

> Jon,
> 
> Thanks for the wisdom on this, you are obviously closer to
> the chip manufacturers than I, so I take what you say as
> accurate.
> 
> It seems hard to believe that someone could reverse
> engineer something like a Permedia III in a very short time.

	It is actually an information theory thing, at least that it how
it was explained to me.  Just take the register spec, hook the chip up to
a specialized logic analyzer, and have it start feeding every data
permutation through the registers.  By observing what registers change
when and how, you'll quickly be able to get a good enough idea of the
basics of how the chip works to be able to figure out the rest by hand if
necessary.  And information theory _guarantees_ that you can always
determine the chip design 100%, given enough time, with a logic analyzer
and register spec only. 

	You can get around this (somewhat, the information theory thing
still holds always) by obfuscating the hardware register interface, but
that dramatically increases the difficulty of the chip design process,
wastes time and money, and can't do anything but make the chip slower.  It
is far, far easier to do the obfuscation in software, and the single
biggest bang-for-the-buck obfuscatory software technique is to hide the
register layout.  Combine that with the use of lots of weird macros and
inline code to make driver disassembly a nightmare, and you have a good
"firewall".
 
> And by the time they did, 3D Labs would have a new
> chip that is faster.

	Right, but giving out the register spec could shrink that time to
the point where the market 'window' isn't long enough to turn a profit. 
Remember, for a lot of these companies, the funding for the next
generation chipset design has to come from sales of the current
generation.  I.e., if you slip and fall you may never be able to get back
up.

> I don't doubt that it could happen, just seems unlikely.

	It has happened many times in exactly the manner I described
above.  On the Slashdot forum attached to the notice of my being hired by
Creative, someone brought up an example I wasn't aware of: the Weitek
P9000 video chipset.  Now, Weitek was best known for making math
coprocessors.  How'd they come up with one graphics chipset design out of
the blue?  By reverse engineering some proprietary Sun chipset, that's
how!  Sun accidentally released a .h file with the full register spec for 
the chipset on some version of Solaris, and Weitek had a 100% compatible 
clone up and running in no time flat.  It was so good, it was even 
bug-for-bug compatible!!  So this is NOT unjustified paranoia.  People 
*have* gotten burned - BADLY burned - many times in the past on this 
very issue.
 
> My problem is this, my application is an OEM thing, I
> will be hard pressed to even BUY DOS to ship on the
> application. Even if I can, it seems like a waste to
> spend extra money on something that is needed to work
> around the H/W supplier not releasing information about
> their parts.

	Yeah, although perhaps there is either:

* A deal you can cut with Deitmar (author of S3VBE20.EXE) to release all 
or part of the source.  I don't see why he doesn't release it anyway - 
the utility is free.  Or,

* You can hack LILO to include the binary executable somewhere and run it 
automatically before booting the kernel (yech!  But it just might work....)

	Of course the _real_ solution is to include KGI in the kernel, so 
you can have full accelerated graphics at boot time.  But....

> I come from the hardware side, funny thing is that it
> seems these video chip people are the ones that are so
> tight with the information.

	They are.  This is not Creative's decision to make.
 
> for everything else data books are freely available.

	Not for the EMU10K (SB Live DSP).  Or any of Creative's other
audio chipsets, actually!  All existing drivers were created from specs
that were themselves created by reverse-engineering back in the DOS 
days.  Something will have to be done about that eventually - my boss 
says that he can almost guarantee that none of the existing drivers are 
100% 'compatible', although I am sure that (especially on the older SB, 
SBPro, etc) it is so close to 100% that it doesn't really matter.
 
> Im glad you got a job at Creative, Im not glad the drivers
> are in Binary format. None of us are perfect, we can
> all benefit from peer review.

	Sure.  But this is a **LOT** better than nothing!!!  And we do a 
pretty rigorous QA process internally, plus I am sure that if/when an 
end-user discovers a bug in one of our Linux drivers, it will be fixed if 
it is brought to our attention.  I will see to it that everything that 
can be done to bring us closer to 'The Bazaar' is done.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed