Slashdot Mirror
Patch for Linux 2.2.2 to Disable PIII PSN
An anonymous reader wrote in to say that Phil Karn has posted a
patch to Linux 2.2.2 that will disable the
PSN. He says
"I'm hoping that this patch (or equivalent) will soon make it into the standard Linux kernel so as to dissuade any
application vendors who might be tempted to use the serial number misfeature."
Pretty cool, but I really don't think it belongs in the kernel.
It's a personal choice as to whether someone wants to allow their serial number to be used or not.
It just missed my two releases unfortunately. I've
....
folded a variant of Phil Karn's patch into both
trees so 2.0.37 and 2.2.something should hopefully
go out with the ID off by default
Shrug, they'll just use your disk serial numbers,
your MAC address, your caller ID
Phil has even better news on his pages - the Applied Crypto case is back in court soon
Alan
I doubt it will become part of the official source. Intel wouldn't like that one bit. Could this be the first time in Linux's history when a political consideration --deference to the interests of an important ally-- precludes a security patch or other important technical improvement to the kernel?
Yeah, why on earth would you want to put low-level hardware control in the kernel. After all, there absolutely no way to modify how the kernel functions by, say, recompiling.
Yeah, right. I don't think politics will enter into it. Contrary to people's paranoid fantasy's, Red Hat does not control the linux kernel. And if Intel tried to make RH release a modified version of the kernel sources with their system, all goodwill they've built up would be shattered. They could be that stupid, but I doubt it.
--
Jason Eric Pierce
It will be part of the official source if it's good. No one here is trying to satisfy Intel. Linux is made to satisfy Linux users.
Hey, we already emulate fp instructions, so
why PSN and allow the user to return anything
they want. Would put a stop to this
silliness.
Now what about all us who keep changing that cpu, and what of dual or quad pIII...which processor will it use this time :).
So, I make a landmine, I put it on the road and it is your choice to step on it or not. OK?
I am going to patch, baaaad processor patch, bad processor
Is there a Disk Serial Numbers burned into the hard drive? I know it has a serial number but I thought that was just a software number and could be changed with something like norton disk utilies.
If such a burned in number exists, how how you access it, what "C" funtion calls should I use, or do I need to use bios calls?
Thanks for the info
Cheez
Every Sun CPU has had a serial number for quite some time. Get in a Solaris box sometime and type:
sysinfo and you can get the serial number. Big deal. I really do not think they are so much for tracking PEOPLE as they are tracking MACHINES. Counterfeit CPU's and all that.
Imagine Bill Gates finding the time in his busy schedule to post FUD on /. about the most successful and open-source-code-prolific Linux vendor in history.
It doesn't automatically distribute your credit card number everywhere. It doesn't send personal infomation to people.
Um, fill out a web form with any type of personal information just once and now it does exactly what you claim it doesn't do. Also, if you buy your computer from an OEM and pay by credit card.
I'm not convinced that what is good for software companies is good for me. There are other ways to protect software from piracy and such without having to infringe on my privacy like this.
It is inevitable that Linux will ultimately support disabling/spoofing of the cpuid, because Linux is developed for people that want to use Linux, not for some greedy software company. That is one of the things that make it so great to use in the first place.
As the Linux juggernaut continues on its path toward World Enlightenment, these software companies you speak of will port to Linux, because the one thing they do know is that they can't stand to lose money/marketshare.
No, it cannot, unless you're bizarre enough to actually run an untrusted program as root. Installing it doesn't hurt a thing (unless you're also bizarre enough to set it SUID).
Depends of course if you have a Cyrix/Centaur processor or not. On these, cpuid can be turned off for user-code, therby causing a fault into the kernel. With proper kernel-side support the cpuid(3) can be perfectly faked without the application even knowing ;-)
This would be a fun kernel module to write...
You _can_ run entire programs under emulation, efficiently too. See Bochs' plans, and talk of x86->x86 JIT translation. And mine -- I'm writing a P3 emulator right now and it will do as you describe. ""x86->x86 JIT" in practice means marking the majority of pages as containing safe code, and that can be done with very fast pattern matching techniques. No worries.
:-)
Heck, it might even speed up some poorly optimised programs
-- Jamie
Linux == patchwork?
I think that maybe having a top-notch UNIX (linux/freebsd) is great, but without a cpuid I think that many top-notch 3D, CAD, and hardware-simulation companies will be unwilling to port to Intel.
You've obviously never heard of a dongle. Much nicer to the customer (I can move the software to a different machine!) and much easier for the vendor (I don't have to program the cpuid of the customers machine into every piece of software I sell.) I'm sorry, but the processor ID does NOT solve any existing problem!
After fighting with vendors to move
node-locked products from Sparc to Sparc,
I've often wondered how this works?
Is it a system call (which could be spoofed
if you have kernel source), or is it an actual
register on the cpu (which would be harder to
work around. You'd have to find all the machine
instructions and plug them with traps. Even
then the vendors could build the instruction
sequence at run time).
So.. How does the Sparc ID work, and how does
the pentium ID work? Inquiring minds want to
know.
-- cary
I don't believe that fakeing the serial number would be possible. I haven't checked myself, but I have it on good authority that the CPU ID is cryptographically signed, using a secret key embedded in silicon. Faking the ID would require extracting the secret key from the processor, which could be made difficult, to say the least.
Yes I know you would have to INSTALL it as root (well you wouldn't have to, depending on your priveleges and the target installation directory), but that doesn't do any harm unless you (a) run it as root; or (b) 'chmod 4755' (or similar) and 'chown root' it.
You most certainly CAN bind software to a certain ethernet address or hard disk, though this is usually only donen with expensive industrial software. And yes, there is *always* a way around it.. but still, the same applies to the pIII serial#. How, exactly, is software supposed to GET this number? By what system call? Replace it...
whammo. Rathern than fight about 'disabling' it, what about 'abstracting' it?
Masquerading it? Making it a user-configurable thing?
Red Hat doesn't control the kernel, but Transmeta DOES. And who owns Transmeta? Paul Allen. And who owns his ass? Intel. All Allen has to do is piss on a CD of Linux and it is OVER for us! No more Linux, no more Red Hat, no more Debian. The entire OS will die. He controls the cards.
Bill just wants to sell his stock and have some fun (he is selling a lot).
BTW, does anyone know how they trapped the F0 0F bug? Would a similar technique be possible here?
Come on, those sites that'd check your PIII # ... how on earth are they going to do it? You'll need a browser capable of doing that - so you're all safe as long as you stick with your old browsers.
And if you disable the #, what keeps the browser from re-enabling it again? (Ok, that won't affect Linux too much, but think about win98, IE 5.0 - they'll just ignore the user)
This all applies to other stuff too - it's not the processor but software. If you use only open-source stuff you can be sure you're not sending anything over the net that you don't want to send.
So now you bought your expansive piece of software locked to work only on your processor. But now your PC just made a lot of smoke (told you not to hot-swap PCI cards ;). Too bad... You needed to finish a work for a client and you'll never get another key in time.
But maybe your competitor is using a cracked version, he won't have this kind of problems...
And I'm sure you can think of a lot more examples where legitimate users have problems because of this. Technology that harms only legitimate users and not the pirates is really no good. Don't buy a Pentium III!
With IPV6 there should be enough numbers to give everybody his/her own IP number. And with the features of IPV6 for mobile computing you can always use the same number.
Now that would be a ultimate ID on the internet.
:-)
- Erwin
Transmeta doesn't. Paul Allen doesn't.
Hell, even Linus doesn't, anymore.
GPL... GPL... GPL...
Can anybody name a usefull OS that has emerged fully-formed from it's creators mind, and hasn't gradually evolved enhanced functionality? Can anyone name any piece of software that had every feature that anyone could possibly want in the very first release? Yes, Linux does tend to accumulate patches. But if the foundation is well designed in the first place, and the patches are intelligently done, this can improve the integrity of the whole, rather than weaken it.
The P-III serial number misfeature is implemented
in the CPUID instruction. No system call or
special privileges required. That's the problem
with this thing -- *any* application can execute
it directly. And as much as I'd like to find a
way to have CPUID return a user-specified serial
number, I don't see an easy way to trap and
emulate CPUID the way you would a privileged instruction. Anybody got ideas?
If Intel can be believed, that's right -- you
need to reset the processor to re-enable the
processor serial number.
I'm still trying to track down any technical
meat behind the report from Germany of a way
to re-enable the serial number misfeature in
software. I get the impression that the hack
involved changing the BIOS CMOS parameters, but
I'd like to know for sure. It sure is annoying to
have to get your technical information from the
mainstream media!!!
Phil Karn
Remember, the most popular OS on Intel architecture at the moment is WinXX. It is inevitable that linux users will be able to block/spoof the cpuid, because that is the nature of the linux community and one of the many benefits of open source.
As for the poor masses that use WinXX, which could be linux users who are forced to use it at work, there may not be the available tools to block/spoof the cpuid. Also, if you use Netscape on linux, you don't have access to the source code. So how are you going to be sure Netscape, or any other proprietary product without source code that you use, isn't pulling your cpuid.
That is the whole point of disabling/spoofing it at the OS level.
I'm still not sure if you are trying to say that cpuid is good and we should not touch it, or it is good but you should be allowed to disable it? Personally, since we are going to be able to disable it anyway, I don't see the point.
Don't buy a PIII based computer with anything but cash. If you buy with a CC or check, then the reseller has a name to link with the cpuid. This information could be stored in a database and then accessed by law enforcement agencies and the like. Or, M$ could require resellers to provide them your name/cpuid when they sell a computer with WinXX on it.
Aw, it doesn't matter anyway. In the future, every new born baby will have a microchip implanted in the brain that will allow the government to track your every move and thought.
You're implications are correct! The linux community should have been able to forsee, anticipate and implement a fix for this problem years before Intel even thought about doing this. Damn, these linux developers are lazy.
As long as we're not dealing with self-modifying code, it's fairly trivial. Just follow all paths execution can take, decoding along the way.
And you have the source to every piece of software you use on your linux system and you have scoured every line of all the source code on your system to make sure it isn't doing something you don't want it to do?
You may be able to answer yes to the above, but what about the general population that is slowing beginning to catch on to linux. I guess you do need to be a programmer to use this beast?
I also looked around for technical details on how Andreas Stiller reenabled the serial number reporting. I hope that c't will see fit to release more technical details soon.
I did find a newsgroup posting that mentioned that the hack had something to do with bringing the processor out of a power management state. Still no details, but it seems plausible given that power management suspend/resumes are often a lot like power-on resets. Also, Intel's previous iterations at power management included a System Management Mode that allowed control over much of the 'internal' state of the CPU.
All of my ramblings in this message are pure speculation at this point... I'm just mouthing off until Stiller releases details.
In the next few years, we will all be carrying
a personal identification card that controls
our entitlement to resources. Computer access,
software access, database access, cash access.
This will be much safer than the simple login/
password authentication systems that you think
are protecting your identity now.
The basic complaint about the cpuid is that it
makes it too easy for you to be identified. Well
that is only security through obscurity. You
cannot measure how well it is working. Can you?
The basic problem is that anonymity provides
safety, or comfort in certain situations. Well
We must as a society define what penalties occur,
and what recourse we have, when that saftey is
violated. Because it will be violated by anyone
seeking an advantage.
Anonymity is almost dead. We need protections
in place to fall back on when it completely gone.
You could scan binaries before loading them and replace each CPUID instruction with an illegal instruction which would cause a trap. Then you're free to do whatever you want. Doesn't Linux handle the F00F bug the same way?
:)
The code in an executable has data in it too (movl $0xDEADBEEF, %eax, the $0xDEADBEEF is embedded into the code). Eventually you'd get data that looked like the CPUID instruction. Then it would get changed to your illegal opcode and the data would get corrupted. Also, instructions are variable length. You'd have to disassemble the whole thing before loading it and then search it. Horribly slow. Who the hell would want a PIII if you had to disassemble every program before running it? In general use, a 486 would be faster!
As for the F00F bug, the kernel just moves the interrupt descriptor table to some place other than the default. For some wierd reason due to the way the pentium handles the address lines for page tables in combination with the cache, moving the IDT cures the F00F bug.
On top of that, Intels only have like 2 illegal instructions. The rest are "undefined instructions", which actually do something (mostly weird modifications of other instructions-- nothing really useful), just it's not documented.
What if i get a PIII, buy lots of programs :-)
that DEMAND that i use the serial onboard,
and then change my cpu... will all the programs
be invalid?
I can't see why som program manufacturers will
do that... It's bad service
It is more like spaghetti. And Linus don't give a damn when a new feaute he introduce in the
klernel brake something in my distro and a month of hard work goes to hell! It is maddening. Oh well, back to work.
Having a net-distributable PSN to avoid piracy is like cutting off your legs to avoid clipping your toenails.. the only thing it's good for is surveillance.
;)
There are existing methods that doesn't enable big brother to look up your arse. Hardkeys, for instance. Nowadays you could use USB for instance, and avoid the 3 foot hardkey chain as well
While people who change their CPU monthly aren't
too common, they surely are people with loads of cash.
I think that maybe having a top-notch UNIX (linux/freebsd) is great, but without a cpuid I think that many top-notch 3D, CAD, and hardware-simulation companies will be unwilling to port to Intel.
Therefore, I say that having a cpuid is a good thing. Not good for the things Intel Marketing is wanting it to be used for (web/portal/sales stuff) but I think that it is good for companies that want to protect their software.
-- Erich
Slashdot reader since 1997
Linux is developed for people to run Linux. Right. Need I remind you that Linux is just a kernel? what I choose to run under my kernel is entirely up to me. And being able to have a nifty kernel under my $10k piece of software. And I really laugh at your ``greedy software company.'' You must be one of those people that think that if a software company is charging $10k for a product that they don't need the extra 10 licenses that you and your friends would use. So you pirate it.
Why has slashdot turned into a WaReZ kiddie hangout? Oh, I pine for the days in which slashdot folk talked about interesting things like pipelined cache access and number theory. Now it's John Katz writing silly articles, people flaming him for it, and stupid people complaining about how the big bad software company that makes specialized software and spends millions in research won't give them a copy for free. GROW UP! If I spend three million on research on hardware synthesis tools and then have five companies that are interested in the product, you can be darn sure that I'm not going to release it under an open source license, and you can be darn sure that I am not going to want people pirating it and stealing money from me.
I hardly think that Linux is on the path for World Enlightenment. I think you're probably a tad delusional if you think that. It's currently one of the least-sucky OS's I've used. I currently use it on all my computers (except my NeXTStation) exclusively. But I think it's a good, inexpensive easy-to-use operating system. Not anything remotely relating to anything important, like God.
But, yes, I think that more companies would port to Linux. And if you're using high-priced tools, You're going to get inferior forms of host identification, like dongles (requires user level access to parallel port), MAC addresses (what if you're not using ethernet?), or disk info (which may need user level access to hardware -- a *really* bad thing).
So, I still say that the cpuid is a good thing for anti-piracy. I don't know if it's a real privacy concern, and I certainly think that if you only use software which you have the source to you can darn well compile out the necessity of having the cpuid even read.
-- Erich
Slashdot reader since 1997
But they don't have it in the processor, but on the motherboard, IIRC. So the number of CPUs is irrelevant. I'd guess that for PIII serial numbers you'll use processor 0.
Or at least not without running the whole program under emulation (OUCH!). The cpuid instruction isn't priviledged, so it won't fault to kernel mode when executed, thus it cannot be simulated automatically. You could start up the program in a debugger, set a breakpoint after the cpuid and tweak the registers.
After this patch is installed, no program, or maybe just userlevel program, can enable it again?
...my root password. how the hell did he guess it?!
If the kernel can control the PSN switching, why not make it one of those settable kernel options? Set the default when compiling the kernel to whatever the user wants, and do one of those "echo 1 > /proc/sys//psn" things to enable it.
Most big software vendors have already ported to Intel (with NT). They'll use the CPUID if it's there, but they can't afford to ignore popular platforms that don't have it.
The disturbing thing about Intel's CPUID is the way they expect it to be used. If Visa (for example) distributes electronic wallet software that requires the CPUID to function, and then makes it a requirement for all on-line Visa purchaces, what are you going to do? You can protest, but the clueless masses won't care. You'll either lose the ability to shop on-line or be forced to make your CPUID available.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Forgive me as a less than expert Linux user, but is there utility in having a security level between root and the average user? It seems like one might want to run installers at such a level, with write access to /usr/local/bin or some such. Can this be reasonably duplicated for most installations with group permissions?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Again, please forgive my ignorance, but is the installer (run as root) prevented from setting the SUID bit? If not, couldn't it just copy over some common executable with its own version, that behaves identically except for enabling the PSN?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
All the patch does is, at bootup, send the CPU the instruction to turn the PSN off. I'm guessing that intercepting the CPU ID instruction would be a little harder. Note that I know very little about the structure of the x86 architecture. The lowest I can go is C.
Someone mentioned above that the CPU ID can be turned back on without rebooting. Is this true? The patch seems to rely on the fact that this bug^H^H^Hfeature can only be altered at boot time.
--Phil (One of these days, I'll get around to learning x86 assembly.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
Trapping an unprivileged instruction isn't possable. The CPU won't generate a fault.
The best possability would be a program that scans the machine code starting from the entry point, and recurses through the branches until it finds the offending instruction. Now, patch in a subroutine call that provides a selected number rather than the real one. If necessary, overwrite several instructions and carry them out in the patch. The patch routine is just crammed onto the end of the code section.
That'd be a real pain to write, but should work. Perhaps some of the game unprotect writers from the 80s should come out of retirement?
If it can run the program, it can parse it.
Why not have it to where a user-level program (or a /proc interface) with ROOT PRIVILEGES can make the adjustment as needed? If you're running untrusted programs or installing untrusted kernel modules as root, you're a moron and deserve what you get. Perhaps have the kernel print a line to the klog saying the ID mechanism was (en|dis)abled by program ____ user ____ so that it can NOT be done secretly?
Exactly.
1. Never run untrusted programs as root. PGP signatures and the like are there for a reason. If you're habitually downloading and running stuff as root without any clear idea where the program came from or who wrote it, you're just asking for trouble.
2. Any program that is discovered to exhibit this sort of behavior will be treated like any other trojan horse. The application will be reported to the various security lists and it will be removed from download.
It seems like everyone is pointing out these "new" threats about how people can write malicious programs to retrieve your CPU ID, but really folks, this is nothing more than a trojan. One could just as easily write in a little bit of code that retrieves your e-mail address, passwords, etc. and mails them to a collection address. The threat of having a CPU ID is negligible when compared to this.
Trust me, if you end up running trojaned software, the CPU ID will NOT be a primary target. Think about it, folks.
While you certainly have that option, it's not going to make the PIII go away, which means it'll still be used with Linux, which means Linux will still need a way to control it.
The CPU ID's could actually serve a useful purpose in a NOC or privileged network where each and every machine needs to be accounted for and identified. Since Linux is popular in these settings, it only makes sense to have the ID available for use.
I was just saying to a co-worker: "Now that the PIII is released, I wonder how long it will take someone to release a [Linux] kernel patch that prevents the serial # from being accessed"...
Good work.
--
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Heh... We could all pick the same s/n to emulate, sort of like logging in everywhere as cypherpunks...
:)
"Gee, Boss, this guy with s/n 1234567890 sure seems to be hitting our site pretty heavy!"
Shawn Asmussen
Considering Linus works for Transmeta, presumably an Intel competitor, I think your logic is faulty.
--
Aaron Gaudio
"The fool finds ignorance all around him.
"Every man is a mob, a chain gang of idiots." - Jonathan Nolan, Memento Mori
Just kidding... :-)
-------
Warning: Slashdot may contain traces of nuts.
The hilarious part to me is that just YESTERDAY somebody was pasting me an excerpt from a news item saying something to the effect that "Other operating systems such as Novell or Linux will probably not disable the ID system..." suggesting that only Win95/98 would be able to.
Nothing worth doing is worth doing today.
What about trapping the serial number and changing it the moment the cpu sends it out.
You see, you know your serial number and can thus make the kernel or any other deamon cactch that number and replace it with some other number or a blank.
Monchi
ps my spam email adress is just a mailbox which is scanned for usefull messages and dumped.
In case you haven't noticed, Linux is a patchwork quilt of enormous dimensions. Every change to the kernel was probably a patch at one point or another.
Planetes
"One World, One Web, One Program" - Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitl
Don't you just *love* open-source?
I thought it was discovered the serial number could be turned back on without a reboot? Does this patch do anything to prevent this?
yeah, what the subject says.
...Linux!
--
"You never know when some crazed rodent with cold feet might be running loose in your pants."
-Calvin
Doesn't autoconf have a "make installdirs" target that will make just the directories, that you can then chown, or am I just on crack?
/opt/packagename or /usr/local/packagename, it's trivially easy to make it such that it's not owned by root and doesn't even have to be installed by root. And on my work account, i'm installing things into $HOME/soft/packagename all the time...
Anyhow, if you install to a root like
Installing software in superuser-owned places is a superuser thing, that's just all there is to it.
I've finally had it: until slashdot gets article moderation, I am not coming back.
If the patch traps the CPU ID instruction, it's irrelevant whether the chip thinks it's turned on or not. All you have to do is stop that instruction from reaching the chip... Now, what I would like to see it a patch that returns a random serial number instead of simply blocking the CPU ID instruction.
0 1 - just my two bits
go read http://www.bigbrotherinside.com/ for the answers to your questions
As I said a while ago. PIII is the best support for Linux and other OSS OSes to be ever released. Now it comes to the point: either use Linux/FreeBSD, etc or loose your privacy rights.
;-)
Lovely...
Intel has unintentionally screwed all M$ users. Beautyful...
I am using AMD anyway
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
read Subj:
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Here in California, caller ID can be set to be blocked by default... (blocked to all but police and 911 and such anyway)
and NIC numbers can be changed (at least with some cards)
You obviously haven't thought this through.
People are replacing the CPU in their computer all
the time these days. Even I have (I actually forgot that for a moment..),
and I'm no "upgrade at all costs" guy.
Can you imagine the hassle to get all your CPU-tied license
servers for all your "top-notch 3D, CAD, and hardware-
simulation" tools working again after a CPU change?
TA
Which seems to imply that it should be a kernel compilation option, n'est ce pas?
Weblogging Considered Harmful:
How about a PIII s/n emulator... ie. a s/n spoofer... It might be nice to see if you could spoof the s/n and cause programs to go beserk. ^_^ Might also help in those sites Intel is planning....
This is a new processor instruction, right? Let's say I have an application that calls this instruction, and I try to run it on a PII or something; it will generate an illegal instruction fault, right?
If so, then the kernel's handler could spoof the instruction instead of killing the application with SIGILL.
So it seems to me that a PIII spoofer would be possible on an older Pentium system.
Maybe I'm way out in left field, though...
Why is everyone so worked up about this? Every
ethernet card has a unique id. Why is a CPU
id worse than that? Is two unique ids per
computer worse than one? Could someone please
explain this to me.
So, on Sun systems, the ID does not come from the CPU, but from another part on the motherboard. Even if you switch processors, the number doesn't change. On an Intel P3 system, the ID is stored in the processor itself, so changing processors changes the ID.
I can see how this would be a pain in the ass if you wanted to upgrade near the end of the year from a 450Mhz P3 to a 550Mhz P3. You'll have to reinstall all of the software that is dependant on that ID, or at least reregister the software.
If Intel is trying to accomplish what Sun did with their ID numbers, they ought to rethink where the ID comes from on the computer. They could stick the ID number in the motherboard chipset, or in the BIOS.
I don't care much about all of this, though. I'm an AMD user.
SaDan
i couldn't think of a more appropriate feature to belong in the kernel. disabled, by default, but nevertheless there.
More ideas on spoofing:
1) all use the same PSN as a protest.
2) use PSN's of machines at Intel.
3) echo back the PSN from the requesting machine.
How is the serial number request negotiated? Is it encrypted?
-D
The problem is not crypto at all. The system serial info (96 bits) is provided upon request by executing a CPUID instruction. This instruction is nonpriveleged so the kernel will have a hard time trapping it.
Thus the problem centers around how to get the kernel to trap this request and emulate, fake, or mangle it.
Does anyone know a work around?
here's some URL's that Phil Karn provides in his patch:
(AP-485) , (AP-909), a href =
"http://www.amd.com/K6/k6docs/pdf/20734j.pdf"> AMD K6