[4042] in cryptography@c2.net mail archive
Intel & IDs (was: ...blabla on IDS and so on)
daemon@ATHENA.MIT.EDU (=?iso-8859-1?Q? "Oliver_Fr=F6mel" )
Fri Jan 22 10:12:31 1999
From: =?iso-8859-1?Q? "Oliver_Fr=F6mel" ?= <ofroemel@prs-gmbh.de>
To: cryptography@c2.net, cypherpunks@einstein.ssz.com
Date: Fri, 22 Jan 1999 05:01:47 +0100
[I'm reminded of a tool I used to have to set the system ID on Suns on
a per-process basis. We only used it to run legitimately licensed
software, btw -- it was just often too hard to get license keys
changed at 2am when a server failed. Anyway, I'm going to let this go through and trim anything similar -- the point has been made. --Perry]
I'll provide a story of my own to illustrate tha matter.
As many of you may know, IBM licenses their C-Set-Compiler for AIX based on
the CPU-ID. Well thought, you may think, because the company that produces
and sells the whole systems should be able to control the manipulation of
this variable. I always thought of checking this out myself, but IBM
convinced us of a possible backdoor themselves.
It worked as follows: After installing a set of PTFs required by another
application (no, I won't go into that discussion AGAIN since working with
AIX for more than a few years as a sysadmin is a nightmare), the compiler
stopped working and complained about an invalid license. We then discovered
after a bit of twiddling around that the little tool used to bring up the
CPU-ID presented us with a set of "F" followed, I think, by an "E".
After reporting that to some IBM Service-Center, we were provided with a
possibility to trick the CPU into pretending it had the required ID for the
Compiler instead of having explained to us why this strange behaviour
occured.
With some years of experience in this field I'd like to doubt that Intel's
proposals will put the right signs.
Any comments?
oli.
