[mdlug-discuss] [mdlug] [Fwd: [opensuse-offtopic]AndnowtheManchurianmicrochip]

[Ingles, Raymond]

> From: Aaron Kulkis

> >  *Except* that we're talking about slipping design changes in at the
> > fabrication level. The people who design the chips test them, and
they
> > know - *very* precisely - what timings to expect... The fabricators
> > *can't* steal silicon without redesigning
> > *something*, cutting into performance margins that are already cut
as
> > fine as the designers can get away with.
> 
> And when the motherboard assembly plant, and the chip fabs
> are both in the same place, and both under People's Liberation
> Army control (like ALL business in China)....

 You're missing something. There isn't just two players here, the
fabricator and the end user. There's the *designers*, many of whom are
based in the U.S. and presumably aren't *all* subverted. Consider a CPU.
They simulate these things in excruciating detail before the designs are
sent to the fab plant. They know the timing constraints and input/output
profiles of each component to a very narrow range. They *have* to,
because for performance reasons they have to know what the best and
worst cases will be, and design things to work within narrow profiles.

 Why narrow? Because 'too tight' and the thing will fail (or yield will
be so low as to make it unprofitable); while 'too loose' and you're
wasting money and performance that your competitors *won't* be wasting.
The designers want - they *need* - to eke out maximum performance. They
know the physics of fabrication as well as anyone, they know what's
possible... and they work to be on the close edge of what's possible,
because if they *don't* they'll be outcompeted. When they get the
samples, they run detailed tests of each component on the chip, both
individually and how they interact.

 Now, you change something behind their backs, and all their detailed
schemes for avoiding deadlocks and missed signals and interference and
overvoltage and undervoltage and heat dissipation - things which they
don't even *share* with the fab plant - go out the window. Look at
Microsoft's Xbox 360 - they screwed up on the heat dissipation big time,
and it cost them at least a billion dollars. (Google 'RROD'.)

 Your Chinese engineers need to be able to reverse-engineer a chip in a
matter of days, add a complex subversion module onto the same amount of
silicon without compromising the function or timing of *any* of the
component parts, and keep yields up to avoid suspicion. For multiple
chip architectures. Over and over again. In the face of regular hardware
revision requests that they have no control over.

> I don't know the specifics, but a standard COTS computer (i.e.
> one of the all too many hundreds of thousands or even millions
> of computer the DOD owns that run Windows) is not going to be
> tested for signal timings on the motherboard.

 But the chipset makers will test their components' signal timings. The
motherboard manufacturer will sure as hell test the motherboard signal
timings, because if they don't they run the risk of shipping a board
that flat out doesn't work.

> >  But if you're doing DMA-related work at the same time, you'll see a
> > major drop in performance. Dang near everything on the system uses
DMA
> > now.
> 
> You would notice a "major drop" if the functionality was added
> in AFTER the computer was installed.  On the other hand, if the
> spy-ware (hard and/or soft) was in the computer from the time
> of purchase...nobody's going to notice a "major drop in performance".

 Wait, the spy module is *always* stealing performance? It's *always*
stealing DMA cycles? Why aren't the manufacturers noting that they
aren't getting the performance they designed for and that their
simulations tell them to expect? "Gee, we're losing 10% of our
performance, all the time. That's funny, but there's no need to
investigate that. After all, nobody in the computer world cares about
tiny performance margins, right? People aren't silly enough to pay $100
more for three extra frames per second in a game, right?"

> Not only that, but the spy-ware doesn't have to be operating
> non-stop constantly.  A busy disk drive on a quiescent system
> would be noticeable...especially on a laptop.  But reading
> and sending just a couple disk blocks at a time, and working
> through the disk drive from start to finish would eventually
> furnish a tremendous amount of data.

 As I've already noted repeatedly, a distributed system capable of
running the equivalent of a 'background task' like that is nearly
impossible to design and implement. Even so, when the system is doing
something performance-critical, dropouts like that are quite
noticeable... even when everything's working perfectly. (How is this
system to know that a major resource drain isn't *about* to come up?) If
there's a flaw in the design (of the nominal system, not the spyware
module) or a bug in the software, you're very likely to trip it. At
which point you have unexplainable but repeatable crashes, which people
*do* notice.

 (Oh, BTW, I knew you couldn't substantiate your charge about taxes. Odd
that that was about the only part of my message you *didn't* quote....
Don't you feel ashamed about trying to use such a baseless tactic just
because you feared your opponent was making good points? Are you really
so callow that winning an argument is more important than figuring out
the truth?)

 Sincerely,

 Ray Ingles                                               (313) 227-2317

 "I would like to see something like custom taxes, where you have a base
   of required stuff to pay, and then you have electives where you can
     have your say in the balancing of funds." - hyrdra, on Slashdot
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.