Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Intel

Upgrade Your Pentium's Microcode 114

Posted by Hemos from the kinda-disturbing dept.
BugBBQ wrote to us regarding a a recent Byte column which talks about BIOS Update, a feature that Intel has built into their chips since the Pentium Pro. One of the interesting parts is that there's no checking to see if a code update is legit, according to the article.
This discussion has been archived. No new comments can be posted.

Upgrade Your Pentium's Microcode More

Upgrade Your Pentium's Microcode

Comments Filter:
  • I wonder if 2 kilobytes is enough to really do something cool with the chip. I mean it can obviously be used to scre up the operation completely, but i wonder if it can be made to run a demo [demoscene.ru] every time it starts up. I know there are 4k and even 1k intros for the PC, but those usually take advantage of the OS services...
  • Quick show of hands here: who here has the skills, time and patience to analyze the performance of your computer and actually find a way to improve the microcode performance on their computer?

    You're absolutely right, but I think the point is that Intel could upgrade the microcode in the event of new performance research, security fixes, or another show-stopper division bug. An perfectly reasonable idea, IMHO.

    On the other hand, I've written some very simple microcode for a scaled-down x86 instruction set, and the ability to run it on a live machine, rather than under emulation, would make a great academic tool for graduate-level students.
  • People releasing harmful microcode. Hmmm. Nope. Don't think I've got to worry about buggy processors . . .I've got an Athlon.

    Argh. The uppity nature of Athlon advocates is getting more than a bit annoying. It's not like the Athlon is some brilliant new processor with no ties to Intel, you know?
  • From Intel's website:

    "The Pentium III processor may contain design defects or errors known as errata that may cause the product to deviate from published specifications. Usually the effects of the errata can be avoided by implementing hardware or software work-arounds"

    I don't find that very reassuring. I mean basically they're saying "Hey guys, our flagship processor is crap, but we MAY be able to fix it.

    Reading things like this serves to reassure me that I made the right decision to buy an Athlon.

  • ..and sorry Transmeta. But this CPU BIOS or "A device that's microcode can be updated via network and provide translation to other chipsets" invalidates your patent.

    You'll be sleeping on the streets by wednesday. Ahahhahaaa!

    - SIGNED BILL GATES

  • I can't wait until someone writes a vb script that I get though outlook that completly messes up the code inside my P3. Oh wait, I use linux and have an Athlon. Damn, that was close.
    --------------------------------------

  • I am going to change the code on all the development boxes so a logical AND will be a local OR, that should mess with the programers head. ;)


  • I just looked at the page you linked, and (despite the initial thought that it was just a hoax, because of the URL), it appears legit. Then I noticed this:

    intel-p6microcode-22June2000.txt.bz2

    My celerons were bought a year ago, and presumably have older microcode.

    So someone else mentioned that "steppings" were just microcode changes. Is that true? If I get the linux microcode update utility and hack my system to use it, what do I get?

    Slightly high system stability?

    Slightly higher system speed?

    Anyone have any information on this? Is it worth doing for any reason other than the cool factor?

  • How this works.. (Score:5)

    by molo ( 94384 ) on Friday October 27, 2000 @05:18AM (#670855) Journal
    The P6 processors have microcode that you can change at runtime. However, these changes DO NOT GET SAVED ACCROSS POWER CYCLES . This is used by Intel to fix some errata in the shipping microprocessor. The way it is implemented, since it is not written permanently, the system BIOS has to write microcode updates to the CPU at boot time, on every reboot. This enables Intel to make revisions take effect with simple BIOS updates that everyone is used to. This was very interesting for me, as I had no idea that BIOS updates held such weight with the P6 family of processors!

    If you look at the PPro Processor Specification Update [intel.com] (the accompanying PDF), you will see that some of the erratum are marked as: "Workaround: It is possible for BIOS code to contain a workaround for this erratum." This indicates an erratum that can be fixed by microcode updates.

    The advantage to having this is significant, in my opinion. You don't have to buy a new processor stepping to get erratum fixed. Granted, there will be plenty of erratum that can't be fixed with a microcode change, but this is at least a step in the right direction.

    As was pointed out by another poster, Linux 2.4 has /dev/microcode support for P6 processors. What this allows you to do is update your microcode on boot. Why would you want to do this? Intel issues new microcode updates to the BIOS writers. If you get your hands on new microcode before there is a full flashable BIOS revision available, this will allow you to install the new microcode at bootup, removing one layer of your dependency on your BIOS writer.

    Anyway, I think this shit is really cool, but not something I plan on using unless there is a serious errata found in my processor that can be fixed this way. It sounds like quite a bit of hastle for marginal benefit in most cases. However, its great that Linux provides us this option.

    Anyone have any ideas about hacking microcode? I donno if Intel releases specs on it. Could be very interesting.
  • Oh, cool! Never received an imaginary mod point before. Thanks fjordboy! :)
    ---

  • No - not true .... (Score:3)

    by taniwha ( 70410 ) on Friday October 27, 2000 @05:44AM (#670857) Homepage Journal
    'Steppings' is a chip design term refering to mask changes (ie changes in the underlying logic). Microcode upgrades are there for a different reason - so you can fix stuff in the field. What they may do is see which mask stepping's being used in order to analyse which bugs are present then load the appropriate uCode fix (the fix might then fake out the 'stepping' id that's returned to the OS so that it in turn can behave differently).

  • While I do not pretend to understand the rationale behind this most bizzare AMD v/s Intel Jihad that I don't participate in, I do beleive in fairness. So, in response to your comment, I went to AMD's website and found a copy of the 3-year limited warranty [amd.com] for your processor. Here is a direct quote:

    AMD does not warrant that your AMD processor will be free from design defects or errors known as "errata". A description of the current characterized errata are available upon request.

    So, it looks like, using your own logic, AMD is saying, the Athlon is crap, but we don't have to fix it.

    Personally, I think what both vendors are saying is "hey... we've made an awfully complex product... and we might have borked it up here and there. sorry... but you can't sue us for it." Right or wrong? I don't really care, but let's not go off half-cocked, shall we?

  • Look here [usnews.com] for more information about this important, divisive issue.
  • What are you talking about? First of all, the P6 core is most definately IA-32. Hell, the 386 is IA-32. That designation refers to the instruction set, not to size of registers, or whatever you are trying to talk about without knowing.

    And no, Ppro does not have 36 bytes for each register. It doesn't even have 36 bits for each register, either. All the general purpose registers are still 32 bits in length.

    The 36 bits you are referring to is the address bus. The P6 core includes a widening of the address bus to allow for more physical memory as well as internal processor enhancements called Physical Address Extensions (PAE) that allow the operating system to use more than 4gb physical memory. The internal structure of segment descriptors has also been changed to allow for larger base addresses. Note that even with a 36 bit address bus, processes are still limited to 32 bits worth of virtual memory space (due to the size of the registers, 32 bits). I'm pretty sure the Linux kernel supports this through the use of the BIGMEM macro.

    If I recall correctly, the address extensions of the P6 generation were actually removed before the introduction of the Pentium Pro, and finally introduced with the Pentium II. Anyway, I've never seen a Ppro based system with more than 4gb physical memory.

    So yes Ppro=IA-32, and now you know why.

  • The code-morphing software is loaded at boot time by the BIOS and then the "door is closed" so that no other changes can occur until the system is reset.

    The old 286 CPU had a similar limitation: the CPU couldn't be switched from protected mode (to access extended memory) back to real mode (to call DOS) without a reset. So the 286 mobo designers put a special reset function into the keyboard controller that reset the CPU in such a way that it left protected mode without causing too much damage. Perhaps a similar technique could open the doors for Crusoe to load in instruction sets dynamically.

  • If I recall correctly, the address extensions of the P6 generation were actually removed before the introduction of the Pentium Pro, and finally

    Nope. Nothing was removed, just never used. There are 36 address bits ON the original PPro package itself. Selector math is done in 36 bits too.

    Check out the specsheet (refer to the alphabetical listing of pin names in the appendix, addresses go from A0-A35):

    http://developer.intel.co m/d esign/pro/datashts/24357001.pdf [intel.com]


    ---
    Unto the land of the dead shalt thou be sent at last.
    Surely thou shalt repent of thy cunning.

  • Contrary to the many other posts here, there are indeed reasons for hacking microcode. 2nd and 3rd generation N64 product developers likely know this already.

    Inserting one or two new, specialized instructions in your inner loop can make all the difference in the world. Being able to leave registers in an undefined state when you truly don't care about a result, terminating an instruction already partially executed, executing instructions in two pieces - all of these are Good Things when you know nothing else is going to be relying on the processor state.

    This could be very useful for performance-critical code in device drivers and specialized applications alike.

  • it's not "microcode RAM", it's a chunk of your on-chip cache. ISTR about 80k, though it's been a while. None of the bugfixes new microcode could give me is worth shrinking the cache on my PPro's.

    I must admit I've got dreams of coding faster strcmp's, though.

  • The microcode on IA-32 processors doesn't do much. All the commonly used instructions are hard-wired logic. The microcode engine is used only for infrequently used instructions where you're willing to accept a performance hit in exchange for reduced transistor count. I think decimal arithmetic, hardware task switching, and similar little-used features are microcoded. But IA-32 machines have never been heavily microcoded like, say the old DEC VAX. In fact, Intel has never used microcode much, compared to, say, Motorola. This reflects the very minimal architecture of early Intel machines.

    In addition, it's possible to turn off some CPU features during boot-up, and make superscalar CPUs less superscalar. That's in there in case a serious concurrency bug is found, so the concurrency can be scaled back. It's comparable to turning off certain optimizations because the compiler is broken.

    But none of this stuff will help performance.

  • so you are saying that a nefarious program can't update your motherboard bios?

  • Using BIOS Update, is it possible to remove or alter the processor serial number on Pentium 3 chips?

    Inquiring minds want to know...

  • Pulling Back The Curtain (Score:3)

    by Fatal0E ( 230910 ) on Friday October 27, 2000 @04:44AM (#670869)
    I didn't even read the entire byte article with exception to the first page. It read like one of those "Intel-Doesn't-Want-You-To-Know-" articles. Scuze me while I yawn.

    This is an excerpt from Tom's Hardware
    What is 'micro code update'? Well, all of Intel's 6th-generation processors have a little area that can store some software ('micro code') to deal with processor bugs right inside the CPU. Usually the motherboard BIOS loads this software into the processor right after boot-up. Each time Intel finds a new bug they try to create a new little software patch that is called 'micro code update'. These 'micro code updates' make the processor more reliable, but they always cost a bit of performance, because they basically turn off some internal features.
    Let's go find a conspiracy somewhere else.
  • You know, this would explain a lot. I think that the PPro, PII, PII, etc, are really all the same chip..... they've just upgraded the microcode! We never knew just how similiar they really all were.

    I mean, this would certainly explain why you can't intermix FPU and MMX instructions.......
    -----
  • if (OS = Windows) {
    printf "Please install Linux.\n";
    crash();
    }
     ---------------
    Or it could be used by Microsoft as well, who knows?
    ---
  • IBM computers check the bios attempting to be loaded and refuse to load a bios for another model, and also warn if the loading bios is older or equal to the current bios. I don't think checking the bios should be the processor's responsibility. It should be the motherboard chipset's.

  • Re:Uh-huh. (Score:3)

    by G Neric ( 176742 ) on Friday October 27, 2000 @04:54AM (#670873)
    Quick show of hands here: who here has the skills, time and patience to analyze the performance of your computer and actually find a way to improve the microcode performance on their computer?

    Quick show of hands here: who has the skills, time, and patience to analyze the performance of your TCP/IP stack and write, debug, and test code to improve it?

    Now, how many have the time to download and install performance enhancing updates if a small number of skilled people make them?

    Oh, I see, we don't all need to do all the work all the time.

  • W00!! Amen brother, I was waiting for someone to say that ;) The true processors are built by a company that doesn't put pansy-ass serial numbers in their processors for them to broadcast and say, "Here I am! Pllllease (a la Roger Rabbit) come hack me and rape my puter cuz you are a 311t hax0r and I worship y0u!" AMD rules! Someday you'll all wake up and thank me for pointing this out when you all have Wintel processors embedded in your skulls and you bow down to Bill in homage to him as he sits on his throne of darkness, filling your mind with evil vile and cruel software and making you the BORG!! RESIST, my friends! Resist and throw off the yoke of burden that has been cast upon you by the Evil Empire! Only then will you know TRUE freedom and be able to walk through the beautiful fields of daisies without transmitting everything you see to the Almighty Bill! Only then will you be able to pet cute little kitties without infecting them with the evil M$-BORG virus! DIIIIEEEEEEE!! DIII- err...time for my pill...please disregard any of the previous statements as products of a delusional psychosis brought on by too many PC crashes induced by late night kernel hacking...
  • For all those worrying about potenrial virii flashing your CPU with bad code and making it worthless - Fear not!. The uploaded microcode is lost on a reboot and needs to be reloaded every time.

    The worst a virus using this technique could do is crash your PC and theres lots of easier ways to do that.

    I've tried the /dev/microcode on 2.3/2.4 simply for the coolness factor. No system differences on my by now old PIII 500 and no loss or gain of any percievableness on any benchmarks I ran.
  • My Asus A7V motherboard has a BIOS Update feature in the BIOS, I'm not sure if this is just a carry over from their Intel based boards but it would not surprise me if AMD added a similar feature to the Athlon line. Assuming the update method and changes are secure (and it appears they are, no one other than intel even understands what the code means or how it works) this is an excellent feature. I believe it's saved Intel from a huge recall like the early Pentium days a few times since the PPro came out. I haven't taken to much of a look at AMD's Athlon Docs (just subscribed to their CDs yesterday). But does anyone know if there is a similar feature, and if not, why Asus is leaving the option in their BIOS? Jay
  • Anybody know if this is vertical or horizontal microcode?

    If you don't know the difference vertical ucode is similiar to very limited assembly where as horizontal is a arbitrary logic implemented via a memory lookup. (I think I got that right, maybe they are reversed, it's been a few years).

    The reason I ask is Vertical code might be easier to change, whereas for horizontal code you'd need to understand alot more about the internal design of the chip.

  • Just in case it wasn't clear -- the microcode update is not permanent. It apparently loaded into what looks like microcode RAM on boot. So, you wouldn't need a new processor, you'd reflash the BIOS on your motherboard.

    Historical note: I used a Perkins-Elmer minicomputer in the late 70s that had user-programmable microcode. You could design and implement your own instruction set. wheee! Talk about highly technical programming. There also used to be a company (can't remember the name) that sold a family of chips that allowed you to build a processor. It was a bit-slice configuration -- each family set was 4 bits wide, and you could stack them horizontally to be as wide as you wanted. 32 or 64 bits wide was no problem. It also had user-defined microcode, as I recall. I wonder if that's still around?


    ...phil

  • Multiplier Unlock? (Score:1)

    by Anonymous Coward
    Could the microcode contain instructions to unlock or change the multiplier on Intel CPUs? O/Cers want to know.

  • Re:Uh-huh. (Score:4)

    by Chris Burke ( 6130 ) on Friday October 27, 2000 @05:22AM (#670880) Homepage
    The purpose of it isn't to increase performance. The purpose is to work around buggy micro-ops by re-encoding the CISC instructions to use different ones (with an inevitable loss of performance). It's to prevent them from having to recall their chips in the event of some big bug. "Oh, don't worry, we'll just send you a microcode update."

    At least, that was what was stated in the EE Times article I read, about 3 years ago. They (the article authors) were highly critical of the idea for secruity reasons, but Intel was swearing up and down that it would be strongly encrypted and all that rot. They were also acusing Intel of using the microcode as an excuse to be lazy. Heh.

    Anyway, this news is so old it is virtually obscured by cobwebs and dust.
  • if its any consolation..if i had moderator points, and if i hadn't posted already, i would have modded that one up. purty funny. :)

  • And processors are usually categorized by bits per instruction.

    RISC [everything2.com] processors, perhaps. But CISC [everything2.com] architectures such as x86, on the other hand, tend to have variable-length instructions. Some x86 instructions can be up to 17 bytes; does that make x86 a 136-bit architecture?

    It's data bus [everything2.com] width.

  • [snip] I also believe that it would be EXTREMELY difficult to get a "trojan horse" that could do anything useful. The microcode is _so_ low level, and accomplishing any kind of useful trickery would need to be done at a very high level.

    To actually install virus code in the processor microcode is indeed improbable - but, what about
    changing the way certain instructions operate? Say for example, that you could make a trap instruction take it's new context from user space?

    It's not necessary for an entire virus to be implemented in the microcode, just something that facilitates that virus' behaviour.

    Or how about something really simple - using some uncommon instruction (FDIV? F00F?) would unlock the PIII serial number?

    Liquor
  • Actually this isn't really all that unknown anymore. The PIII 1.13GHz chip REQUIRED a new BIOS and microcode update. Check out Tom's Hardware [tomshardware.com] for their PIII 1.13GHz review (the one that led to the recall, incidentally) for details. But, basically, without the microcode, the processor was very flaky. Tom thinks that it was simply an OC'ed processor, and the microcode was used to disable certain things for stability...that was the impression I got anyway.
  • Non Intel motherboards do this too. They all license it.

  • I for one will not buy ANY Intel cpu's as long as I do not have a way of PERMENTLY disable the CPUID in the microprocessor. Looks like Intel could supply a bios update to do this. If not, any retired microcode ppl out there wanting to take a stab at this?
  • I was under the impression that there's no checking to see if an Intel Processor's code is legit...

    ----

  • > The article says: In technical terms, "BIOS Update" is a hidden
    > (i.e. barely documented at all outside of Intel) feature...

    I agree with you, it's no where near 'hidden' or 'barely documented'. I'm a software developer, and during a couple hours research that I did a month ago before buying a replacement for my burnt out CPU, I easily came across this fact, and I figured, hey, that's innovative!

  • At the same time, if you wre not worried about binary backward compatibility, you could do away with the legacy cruft in the Intel architecture and produces some sort of pseudo-RISC instruction set, that might well outperform the hideous x86 machine code in all it's non-glory. Since you have the source for gcc and linux "all" you have to do then is produce an optimising compiler...
  • I hope that this will allow us to get those anoying broadcasted serial numbers out of the pentiums for good. If they won't do it, looks like we will be able to get in and do it ourselves.

    Though this is very scary from the point of view that it will allow for a whole new generation of Viruses to be spawned. boot sector now bios sector....
  • Not Sucks, Thrifty. How do you think they got rid of all the pentium serial numbers without retooling. Being able to move quickly in a fast moving market is smart.
  • The OS gets in the way of any self replicating virus that could even be concieved to run on one of these. No instruction in microcode can tell outlook to mail the first 50 people in the address book. A virus in the OS on the other hand....

  • The most interesting, funny, etc. BIOS Update hack.
  • Pentium Pro is not IA-32 (it is according to byte). Ppro has 36 bytes alloc'd for each register.
  • Are you fucking retarded? You can disable the stupid serial number. Nobody cares about that anymore. It's yesterday's news. But hey, if you want to do your stupid "Ooh look at me! I'm a pretty H4x0R!" go ahead.
  • The root meaning of stepping comes from the use of Steppers in the Lithography portion of chip manufacture. Stepers are the photography equivelant of an enlarger. A new stepping means putting a new negative in the enlarger which is a hardware modification to the chip design. The negative in a stepper is called a RETICLE and many times it is a positive and not a negative and is used with a postive photoresist. A web search on steppers & Lithography will provide more information on this interesting subject.
  • Absolutely! Due to consumer feedback Intel put out a software patch that disabled the serial number, but because it was a BIOS patch, someone else (who knew what they were doing) demonstrated how to run a JAVA program by visiting a website that turned it back on. I don't think the turn on code is very wide spread on the web. But if you turn off the number, be sure to check for it on a regular basis. Write flame mail to the website that turns it on without letting you know first. No need to flame a demonstration site.

  • IIRC this is similar to the way the Transmeta Crusoe chips work. The code-morphing software is loaded at boot time by the BIOS and then the "door is closed" so that no other changes can occur until the system is reset. I believe that details of this was talked about by Transmeta way back when the Crusoe range was launched.

  • ...to realize that someone just HaX0red your Topic image for Intel and replaced it with one for X-Drive...
    ---- Hey Grrl Geeks! Your very own geek news site has arrived!
  • Yeah, or maybe "bits" or whatever they call them, those small things that can only be either here or not here...
  • because when I looked at your site with IE4 Mac the Intel logo was right where it was supposed to be.
    Set Emily Litella mode ON:
    Never mind!
    Set Emily Litella mode OFF.

    ---- Hey Grrl Geeks! Your very own geek news site has arrived!
  • <i>Since Halloween is fast
    approaching, we're going to let you
    in on a deep and dark secret.</i>
    <br><br>
    <b>Intel Sucks</b>
  • BIOS Update In technical terms, "BIOS Update" is a hidden (i.e. barely documented at all outside of Intel) feature, that can fix bugs by patching the microcode inside the microprocessor. The patches, which are provided by Intel, are loaded by the BIOS when the processor boots up and are contained in a 2,048-byte-long BIOS Update data block.

    This is what allows Intel to provide for those mysterious things called "steppings" when you look in your dmesg's or if you (heaven forbid) use NT, by looking in the system properties.

  • Cool! (Score:5)

    by hey! ( 33014 ) on Friday October 27, 2000 @04:17AM (#670904) Homepage Journal
    Now I can talk to the midichlorians who live inside my CPU...
  • I thought I heard of a technique that could arbitrarily turn it back on again or something similar with some very simple code that can even be operated remotely.
  • 36 bytes per register?? I think bits. And processors are usually categorized by bits per instruction.
  • Well the BIOS has little bearing on the CPU where the ID lives.
  • But I do think if a cracker gets away with the checksum and able to out a bogus MicroCode update then That I see as a problem or at least a messed up way to kill someone machine.
  • So, how long until we see an e-mail virus that breaks your CPU so that you need to reinstall the microcode?
  • I don't think they meant this was equivical to someone clock chipping a system and improving all aspects of performance. I think it was directed at specific applications. At least that is what I got when I read it. And to use their analogy it is like the early era of cars and although the probability of someone being able to use this information to update the speed of their computer is small as time goes on and if this feature is kept it won't be long before someone figures it out and it becomes an easy way to squeeze just a bit more performance out.
  • Updating the microcode on your CPU is NOTHING to do with updating your BIOS. Yes, BIOS updates usually include updated microcode which is squirted onto the CPU at boot time, but that's where the relationship ends. As other posters have pointed out, you can even update the microcode of your CPU under Linux using the new 2.3/2.4 interface.

    As to concerns about security; well, I wouldn't be so naïve to say it'll /never/ be exploited, but it's fairly safe - the microcode is reset on boot.

  • EPROM=Erasable Programmable Read-Only Memory
    EEPROM=Electronically Erasable Programmable Read-Only Memory

    EPROMs must be UVd to be erased, but EEPROMs can be erased electonically (usually, by applying a higher voltage)
  • Yeah but it would make a rather good denial of service attack...

    Talk about a killer virus...

    Most of us would end up buying a new processor.

    Anyone with this compiled into their Linux kernel? Can we do it with an app on Windows?
  • Hmm... I think not (even if you mean bits, not bytes ;)) The P6 has 36-bit addressing, but that isn't the same as 36-bit registers. The registers are same-old 32-bits, just like the 386. To even get at those high 4 bits of address you have to screw around with the paging mode, and you can't have enough entries at the top level of the page table to use all combinations of the high 4 bits... But I digress. The reason you have to do all this is because the registers are only 32 bits.

    PPro is IA-32 in the same way that the PII is IA-32, because the PII is the PPro core with some tweaks (and stripping 4 bits from your data path is not a "tweak" by any means).
  • Microcode is flushed each time you reboot.

  • ...or pehaps I wasn't clear. I wasn't expecting this to allow me to actually change the physical serial number on the chip -- rather, I'm wondering this:

    If this BIOS "patch" area updates the chip's microcode (fixing a bug in an instruction, for instance), the it seems to me it could be patched to disable or alter the instructions that retrieve the CPU serial number.

    Or is this what system BIOS' are doing already, when they have an option to "disable CPU serial number?"

  • Cool signature!!!!

  • Re:Uh-huh. (Score:5)

    by American AC in Paris ( 230456 ) on Friday October 27, 2000 @05:35AM (#670918) Homepage
    I'd maintain that upgrading one's microcode is a fundamentally different task from upgrading one's TCP/IP stack, or most other tasks at higher abstraction levels.

    As you step up abstraction levels, you begin to get into all sorts of possibilities for less than optimal performance, mainly because your code relise much more heavily on single-line commands that fire off larger blocks of less abstract code. The possibility for optimization comes in when coders can look at these layers of abstraction and find more efficient possibilities, either by selecting different procedure calls or by stepping down to the next lowest layer of abstraction (i.e. putting assembler code into a C program to dump graphics more quickly to the screen buffer.) Basically, the higher up the abstraction level you get, the more different coding paths you can take to get the same end result. Finding a more efficient one requires a bit of work, yes, but there are enough other possible routes that the programmer didn't follow that you can probably find one way around it, even if all it is is re-writing the higher level code in a lower level chunk to skip over a few cycles.

    With microcode, though, there are no additional layers of abstraction between the code and the processor. Microcode is as close as you can get to the chip before you break out your oscilloscope and multiplexer. The only way you can improve microcode is by actually finding a faster/better way of sending the command through the chip; though this is mathematically less challenging than trying to optimize at higher levels of abstraction, it also means that the engineers that wrote the microcode in the first place had a lot fewer possibilities to consider than they would have had they been writing C code. You can't "drop down" to the next layer of abstraction with microcode, either, so that entire family of optimization tricks can't even be applied to microcode.

    Finally, upgrading one's microcode works only within a very limited scope. You may find that Upgrade A does good things for your machine, because you run a particular mathematical operation over and over, but for your friend's machine, it actually degrades performance, because of a pipeline trick in Upgrade A that was designed specifically to speed your particular mathematical operation. A TCP/IP upgrade, on the other hand, relies on the lower abstraction layers to handle the finer points of chip tuning, making it's performance improvements much more likely to be universally applicable. (Note, too, that by stepping down to lower abstraction layers to improve performance, one runs the risk of creating greater usage-specific issues, much like in the example above.)

    To successfully upgrade something like the TCP/IP stack, you need some pretty heavy understanding of the protocol, language, and current implementation to succeed in upgrading it. To improve the microcode, you need nothing short of a truly pedantic understanding of the Pentium architecture itself. There's a big leap in skill and opportunity between these two. If there are even a handful of non-Intel developers out there who feel comfortable enough tackling this problem, I'd still be surprised if they managed to yield a universally-applicable microcode patch for the Pentium. It would certainly be no small feat.

    But again, I do ask that if somebody manages to do it, pretty please, let me know...

  • I know for sure that 2.4.0-test9 supports these microcode updates at boottime (there's an option now in the kernel configuration to do stuff with this). The thing is, microcode updates are erased each time you reboot. See http://www.urbanmyth.org/microcode.html" [urbanmyth.org] (I think that's the URL).
  • If you have taken a full digital logic course in college (1 semester), and take a VHDL course, you can design a CPU.

    It amuses me that almost every introductory book on hardware design with Verilog or VHDL uses designing a CPU as an example/exercise. I've one book (Digital Design with Verilog HDL, by Sternheim, Singh, Trivedi) which actually starts with a CPU as its first project, and then advances to a UART serial controller and a floppy disc controller.

    The moral is that CPUs running microcode are actually one of the easiest things to design. Most of the circuitry of a modern CPU is taken up with cache, look-up tables and multipliers; the actual control logic to decode microcode instructions is dead simple.

  • Given the horribly buggy and unstable state of 2.3 or 2.4,

    Do ye know from what ye speak? I've been running 2.4 on a non-overclocked SMP system for close to a month now without any instability whatsoever. This is with X, VMWare, CD burning (thus using the SCSI layer and ide-scsi abstraction/emulation module), encoding MP3 and various other processor(s) intensive tasks. Oh yeah, AND running linear "RAID" and ReiserFS. Yeah, nice and unstable... I have to reboot all the time.

  • Let's see... Intel has "updatable microcode," but Transmeta has "updatable microcode and a commit/rollback register structure."

    But then again, the old Z80 [everything2.com] processor also had a potentially commit/rollback register structure. However, <IANAL>patent law states that to invalidate a patent claim based on prior art, all parts of a claim must be referenced in one item of prior art, or that combining them must be obvious to anybody skilled in the art.</IANAL>

  • Workaround: It is possible for BIOS code to contain a workaround for this erratum.

    The FDIV (floating-point divide) bug in the first run of Pentium processors was due to five errors in a lookup table for division. Unless this technology allows for updates to the ALU's lookup tables, "Houston, we have a problem."

  • Hey weenie boy...and I quote, "Please regard any of the previous statements as products of a delusional psychosis brought on by too many PC crashes induced by late night kernel hacking..." So get a life and a sense of humor ;)
  • There also used to be a company (can't remember the name) that sold a family of chips that allowed you to build a processor.

    AMD. The Am2910 being the microsequencer, Am2901 4 bit ALU and Am2904 word logic module. Haven't seen one as a real object, but simulated this is the machine all CS students at TU Munich have to do some microprogramming on.

  • Clarification: the P6's decoders don't work the same way, that much is true. But the first decoder of the decode group can decode instructions of up to 4 micro-ops in parallel with the two 1-uop decoders (if the instruction would generate more than 4 uops, the decoding stops being an one-cycle thing). So, if I'm any good at reading an AC's mind, I'd say that the two "minor" decoders are hard-wired to output uops for just these instructions because the one-uop instructions can be translated trivially.

    Since the decoder group can put 4+1+1 == 6 uops into the reorder buffer per cycle (provided that the instructions are a properly aligned 4-1-1 uop group), you'd hardly get "a third of your possible micro-op issue rate" from just the one decoder.

    Disclaimer: I'm writing this at 4:30 AM local time (18h personal uptime), so I can't be said to know anything about anything. Yes, I know a bit too much about the P6 core, yog-sothoth help me.

  • "opcode" == the interrupt you just set the regs and run an int, then read...
  • Not a discussion of motherboards. It's a discussion of processors. Actual upgradeable microcode on the CPU itself.

  • bug in the first run of Pentium processors

    Yeah. Exactly. *First* Pentium processors. This microcode update is only available on the PPro and up (P6 cores), not the P5s.

    ---

  • Drat...some of us are still using really old computers and we don't have EEPROM or even EPROM and we have to get a UV box and flash our chips to upgrade our bios. You ppl are way too spoiled. Gotta go...the punchcard machine is overheating.

  • No doubt posted from a machine with an ethernet card. All of which have unique burned in serial numbers traceable whereever you go on the web. Do you ever read the news?
  • People releasing harmful microcode. Hmmm. Nope. Don't think I've got to worry about buggy processors . . .

    I've got an Athlon.
  • Highly unlikely, I doubt any of the processor's instruction logic is at all connected to the multiplier locking.
  • ...

    At first I was a bit interested in what the article said, because from the slash page, it appeared that Intel was being nice and tossing us something to have fun with.

    But upon reading the Byte article, this is mainly aimed at scaring people into a massive Jihad against Intel...

    ]Crazed Mob: Intel is inside my computer...

    }Non-crazed mob: You can't sue... they've labeled the computers so that you know... YOU KNEW...

    ]Crazed Mob: It doesn't matter, we're crazed and out for blood... burn our Pentium Pro's!!!

    }Non-crazed mob: This should be interesting... HEY STAND REALLY CLOSE TO THE FLAMES AND INHALE...

    Does Byte think that anyone who knows nothing of computers understands that article? They'll read it once... think... "Oh, Intel is gonna fix it free? That's nice..." and then if they read to the bottom, get worried and call their local computer "guru" and demand he stop uber-evil "Hackers" from penetrating their pentium chips...

    **thinks** You know, that sounds kinda kinky...



  • Old news ... (Score:3)

    by psergiu ( 67614 ) on Friday October 27, 2000 @04:24AM (#670936)
    Seems like the Byte editor never tried an 2.3 or 2.4 kernel.
    The /dev/cpu/microcode option is there for a long time now.

    --
  • The funny thing is that this has been a commonly known feature to any system builder for years. Most updated bioses that an end user downloads and flashes to the bios at the same time updates the microcode. The only reason that this might NOW become an exploit is that the feeble minded script kiddies are reading it here on /. But most likely they will just end up ruining there motherboard in the process. I most cases anyway you physically have to move a jumper on the motherboard to enable cmos writing.
  • Only the older bios need to cook in UV for a while.
    You make it sound like they're food or something. Oh wait, they are chips...
    ---
  • Thought I would mention that, since last summer, you can update the microcode of your P6 family chip under Linux. The utility is here [urbanmyth.org]. It's been in since 2.4.0-test1-ac10 and there's a backported patch to 2.2.18pre3 as well.

    There's some updated microcodes up there too. Unfortunately there is basically no information at all as to what the updates fix/update/change... any such information would be appreciated.

  • The real problem with Intel is... (Score:3)

    by NickWeininger ( 175454 ) on Friday October 27, 2000 @05:05AM (#670941)
    ...they document the processor state REALLY POORLY, and as a result it's really hard to pin down either (a) what you need to do to get everything "set up right" at boot, or (b) how long it's going to take to execute any given instruction under any given circumstance.

    This is very frustrating for those of us who need to write deterministic-performance (i.e. real-time) code, since it makes it hard to formally derive any reasonable guaranteed upper bounds on the execution time of anything.

    The microcode update thing discussed in the Byte article is a particularly glaring instance of this lack of documentation. Not too long ago, I was working on a special-purpose real-time OS, and had to look through the whole PII family documentation to make sure the OS was "doing the right thing" wrt all the registers on the PII. There is ONE mention of the "microcode update signature register" in the entire 3-volume processor manual, and the mention gives no clue as to what the register's function is, when it can be set (not in user mode, one hopes!), or how it interacts with anything else.

    I emailed Intel's tech support about this, and the guy responding to the email had no idea what I was talking about. When I pointed him to the page number in the docs, he went and checked with the developers, and returned with a vague answer that gave me essentially the same information printed in the Byte article. In the end we figured out that as long as the OS left it alone, we didn't need to worry; but that was a lot of time wasted because of Intel's opacity.

    In fairness to Intel, other processor docs aren't much better in the determinism/precision department. However, Intel's architecture is peculiarly byzantine, since it consists of layers and layers of backward compatibility kludges grafted clumsily on top of one another, so Intel ought to feel a special responsibility to document their rat's nest of a processor properly. On the other hand, maybe they're too embarrassed to do so.

    Nick Weininger

  • A bit more about P6 microcode patching (Score:5)

    by Anonymous Coward on Friday October 27, 2000 @05:05AM (#670943)
    1. Microcode viruses are highly improbable. The code is loaded by BIOS without checks, but the processor checks the code and won't use it unless it is valid. Further, the update is flushed out by every RESET.
    2. There is no benefit to being able to patch microcode for performance, despite what this article states. There is only one decoder (out of three) on the P6 which will load the micro-ops from the patch area. So you get a third of your possible micro-op issue rate. About the only thing microops can do that you cant from macroops is 3 operand instructions (and a few more scratch registers, but those aren't handled by the shadow register table, so you'd have to be very careful).
    3. update space is TINY, especially for the size of the microops themselves. There probably isn't enough space to implement a complicated algorithm even if someone wanted to. Most updates contain less than 10 microops per problem.
    4. To do an update for a particular stepping would require the complete microcode listing for that stepping, because there is no jump table, just absolute offsets into the internal ROM. These are different by stepping, and of course family.
    5. Reverse engineering microcode, aside from being a waste of time, isn't going to be particularly easy. Determining the decryption where the plaintext is just as incomprehensible is a complex task, and there is no observability except whether or not the patch got loaded.
    6. This is not "secret", although hard to obtain now I suppose. The "P6 BIOS WRITERS GUIDE", which used to be available from an FTP site at Intel, had the complete mechanism for loading updates. Windows versions have some form of a microcode loader, to account for defunct bios vendors..
  • The only reason that this might NOW become an exploit is that the feeble minded script kiddies are reading it here on /.

    For dubious values of exploit. The impression I gathered is that the processor has to be re-patched by the BIOS every time the system starts up. Besides, there're already viruses out that trash your BIOS [f-secure.com].

    The only thing of significance that I can think of is that if the microcode path is actually stored in the CMOS (hard to tell from the Byte article -- they keep referring to it as "BIOS Data"), then on a system that protects the BIOS from being casually reflashed (via a jumper or what-not) malicious code could hypothetically write data into the CMOS that would prevent the CPU from being able to run after it gets patched.

    But, if someone can write to the CMOS, they can do plenty of other nasty things, anyway. And the worst case scenario would involves physically resetting the CMOS, which could just as easily be necessary if a virus were to throw a boot password in there. So the short, medium, and long of the situation is that, from a security standpoint, I believe it's a non-issue.

  • The update utility itself is here (Score:4)

    by florin ( 2243 ) on Friday October 27, 2000 @06:59AM (#670947)
    This is actually a very useful function. Suppose you have an older motherboard and you want to run a newer chip on it like a modern Celeron or Coppermine. For whatever reason, even the latest BIOS that your manufacturer has posted on their website does not support it. What can you do?

    Well thanks to this update facility, you can add the relevant microcode updates to your BIOS yourself, and there's a little DOS utility from Intel that'll help you do it. Go to this web page [stack.net] and download at least the files pupdt513.zip and pep15.pdb (the other files may be of interest too). I'm linking directly to the download section as the rest of the site is in Cyrillic.

    First a warning: never run checkup5 without the -u command line option or it will update your flash ROM without asking for confirmation! Typically one would start the program like this:
    checkup5 -u -p pep15.pdb

    Case in point: My very very old Abit BX6 rev 1, though recently provided with a fresh 21/02/00 BIOS, does not officially support Coppermine CPUs. It does have the proper voltage settings but Abit says: "BX6 Rev 1.00, 1.01, 1.02, etc. (BUT NOT BX6 Rev 2.0) do not support Coppermine CPUs due to the native design of power for the CPU core voltage probably not being sufficient. So to avoid instability, we advise that the afore mentioned boards do not support Coppermine CPUs".

    I was aching for speed and Abit's advice wasn't very satisfying, so I put a PIII-700E in regardlessly and it worked fine even without the microcode support, but I wanted it anyway and so I ran an earlier version of the utility. This was the initial output:
    ------------------------------------------------ --------------------
    Processor Update Utility for Intel(R) P6 Family Microprocessors
    Version 5.01, 04/06/99
    Copyright 1999-5, Intel Corporation.

    Unannounced Intel processor detected (CPUID=x683)

    Your system BIOS does not contain a microcode update for
    this processor. Therefore, no microcode update was loaded.

    This utility can load a microcode update (revision 10)
    for your main processor.

    The microcode update was successfully loaded.
    You do not need to run this utility again, unless a new
    processor is installed or a new version of the utility is used.
    ------------------------------------------------ --------------------

    Now I get this:
    ------------------------------------------------ --------------------
    Unannounced Intel processor detected (CPUID=x683)

    Your processor contains a microcode update, revision 10.

    The microcode update already loaded in your main processor is the
    latest revision as of 04/06/99. No changes are needed.
    Please make sure you have the latest database file.
    No changes were made to the system.
    ------------------------------------------------ --------------------

    Note how it says 04/06/99 because that's the release date of the program version I used (only supported up to Katmai), however the external pep15.pdb that I used has far more recent updates in it as this list shows:
    ------------------------------------------------ --------------------
    Processor steppings (revisions) and microcode update revisions included in current base

    Processor/Package/PKG Stepping/Microcode Update Rev

    Pentium Pro Processor, PGA, 0x612/00, 0xC6
    Pentium Pro Processor, PGA, 0x616/00, 0xC6
    Pentium Pro Processor, PGA, 0x617/00, 0xC6
    Pentium Pro Processor, PGA, 0x619/00, 0xD2
    ??????????????????????????????, PGA (?), 0x630/00, 0x13
    ??????????????????????????????, PGA (?), 0x632/00, 0x20
    Pentium II Processor, SECC, 0x633/01, 0x34
    Pentium II Processor, SECC, 0x634/01, 0x35
    Pentium II Processor, SECC, 0x650/01, 0x40
    Intel Celeron Processor, SEPP, 0x650/01, 0x40
    Pentium II Processor (?), Mini-Cart (?), 0x650/02, 0x41
    Pentium II Processor (?), MMC1/MMC2 (?), 0x650/08, 0x45
    Pentium II Processor, SECC/SECC2, 0x651/01, 0x40
    Intel Celeron Processor, SEPP, 0x651/01, 0x40
    Pentium II Processor, SECC/SECC2, 0x652/01, 0x2A
    Pentium II Processor (?), Mini-Cart (?), 0x652/02, 0x2C
    Pentium II Xeon Processor, SECC, 0x652/04, 0x2B
    Pentium II Processor (?), MMC1/MMC2 (?), 0x652/08, 0x2D
    Pentium II Processor, SECC/SECC2, 0x653/01, 0x10
    Pentium II Xeon Processor, SECC, 0x653/04, 0x0B
    Intel Celeron Processor, SEPP, 0x660/01, 0x0A
    Intel Celeron Processor, PPGA, 0x665/10, 0x03
    Mobile Pentium II Processor, Mini-Cart, 0x66A/02, 0x0C
    Mobile Pentium II Processor, MMC1/MMC2, 0x66A/08, 0x0D
    Mobile Intel Celeron Processor, MMC1/MMC2, 0x66A/08, 0x0D
    Mobile Pentium II Processor, Micro-PGA1, 0x66A/20, 0x0B
    Mobile Intel Celeron Processor, Micro-PGA1 0x66A/20, 0x0B
    Mobile Pentium II Processor, Micro-PGA1, 0x66D/20, 0x07
    ??????????????????????????????, SECC/SECC2 (?), 0x670/01, 0x06
    ??????????????????????????????, SECC/SECC2 (?), 0x671/01, 0x03
    Pentium III Processor, SECC/SECC2, 0x672/01, 0x10
    Pentium III Xeon Processor, SECC, 0x672/04, 0x38
    Pentium III Processor, SECC/SECC2, 0x673/01, 0x0E
    Pentium III Xeon Processor, SECC, 0x673/04,0x2E
    ??????????????????????????????, SECC/SECC2 (?), 0x680/01, 0x14
    Pentium III Processor, SECC/SECC2, 0x681/01, 0x0D
    Pentium III Xeon Processor, SECC, 0x681/04, 0x10
    Mobile Pentium III Processor, MMC2, 0x681/08, 0x0F
    Pentium III Processor, FC-PGA, 0x681/10, 0x11
    Mobile Pentium III Processor, Micro-PGA2, 0x681/20, 0x0E
    Pentium III Processor, SECC2, 0x683/01, 0x0C
    Pentium III Xeon Processor, SECC, 0x683/04, 0x0F
    Mobile Pentium III Processor, MMC2, 0x683/08, 0x08
    Pentium III Processor, FC-PGA, 0x683/10, 0x10
    Mobile Pentium III Processor, Micro-PGA2, 0x683/20, 0x07
    Pentium III Processor, SECC2, 0x686/01, 0x07
    Pentium III Processor, FC-PGA, 0x686/10, 0x08
    Pentium II OverDrive Processor, PGA, 0x1632/00, 0x02
    ------------------------------------------------ --------------------

    Lastly, from the Intel documentation:
    ------------------------------------------------ --------------------
    System BIOS code on motherboards based on P6 family microprocessors contains microcode updates that are specific to each silicon stepping (revision) of the processor. Integrators must ensure the microcode update matches the processor stepping used. When the BIOS does not contain a microcode update that matches the processor stepping, integrators must install the latest microcode update in the BIOS before shipping the system. Historically, systems based on P6 family microprocessors have been updated by upgrading the entire system BIOS with a new revision of the system BIOS that contains the correct microcode update for the processor. However, such a process may be time consuming when assembling and configuring many systems.

    Intel has worked closely with BIOS developers to implement a processor update Applications Programming Interface (API), which allows just the microcode update within the system BIOS to be
    installed as needed. Motherboards that contain a system BIOS with the Intel-defined processor update API can be quickly and easily updated, if required, without need for a complete system BIOS upgrade.
    ------------------------------------------------ --------------------

    Have fun, try not to break anything.
  • dude, your post was really good! That is a truly great idea.

    Moderators (actually, I'm one at the moment but I'm participating here at the moment so I can't moderate) please take note: DGolden in a couple of lines said something far more interesting than that long-winded boring karma whore posted by American AC in Paris that he was replying to. Why was that moderated so high, and this one not at all?

  • Read the context. I'm talking about non-intel motherboards supporting intel processor microcode updates. For instance, when I get a BIOS update for my ASUS P3B-F, it has newer microcode updates from Intel for my PIII, and knows to update the processor at boot time with it.

  • Uh-huh. (Score:5)

    by American AC in Paris ( 230456 ) on Friday October 27, 2000 @04:27AM (#670957) Homepage
    Upgrade Your Pentium's Microcode, indeed.

    Quick show of hands here: who here has the skills, time and patience to analyze the performance of your computer and actually find a way to improve the microcode performance on their computer? Hell, that's one step removed from digging out your soldering iron and microsocpe to 'clean up' some of those slow pathways on your chip.*

    Even with the complexity of Pentium chips, the odds of being able to successfully perform an "upgrade" of your Pentium's microcode is slim to none. Microcode is designed to be hella-fast, by people who do happen to know what they're doing and have access to every technical spec they could want on the chip.

    Despite your potentially vast knowledge of microcode, the complexity of the Pentium chip is sure to present some major headaches, even if you have worked out the theory of what you need to do to improve the code.

    Unless you have a very specific set of tasks you run on your computer (and then know exactly what changes you need to make to further improve on the existing microcode,) the odds of your writing a microcode upgrade that actually improves overall system performance is pretty low.

    Having said that, do send me a copy if you manage to do it...

    * BTW, this doesn't work. Learned that one the hard way... *grin*

  • Umm, okay... (Score:3)

    by Anonymous Coward on Friday October 27, 2000 @04:30AM (#670959)

    The article says: In technical terms, "BIOS Update" is a hidden (i.e. barely documented at all outside of Intel) feature.... I work for a company that sells Intel products (a small reseller, $2M a year), and we've known about the feature since the Pentium II's introduction. At trainings for "system integrators", Intel has waged a very aggressive campaign of making sure that, along with proper BIOS updates, we install processor "step updates".

    Based on the low-level nature of microcode, I do not believe that anyone w/o intimate knowledge of the design of the processor hardware itself would be able to write workable microcode updates. Even if someone did, I also believe that it would be EXTREMELY difficult to get a "trojan horse" that could do anything useful. The microcode is _so_ low level, and accomplishing any kind of useful trickery would need to be done at a very high level.

    No doubt, there'll be a lot of posts about how "sinister" this feature is-- especially given that Intel doesn't document the feature-- even though it's been publicly documented for years. Hit the Intel Developer Site [intel.com] and search for "Microcode update". I get 21 hits on that search, most of which are relevant. Intel doesn't give the stepping update utility out to the public, but if you update the BIOS on an Intel motherboard, you generally get some stepping updates loaded as well. Not sure about non-Intel boards.

Slashdot Top Deals

Mathematicians practice absolute freedom. -- Henry Adams

Close