Slashdot Mirror
Upgrade Your Pentium's Microcode
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.
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 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?
"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.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
You'll be sleeping on the streets by wednesday. Ahahhahaaa!
- SIGNED BILL GATES
--Giving to trolls for the benefit of us all
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.
--------------------------------------
--------------------------------------
in a world without bounderies or fences, who needs Gates anyway?
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.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
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?
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!
/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.
If you look at the PPro Processor Specification Update (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
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.
Using your sig line to advertise for friends is lame.
Oh, cool! Never received an imaginary mod point before. Thanks fjordboy! :)
---
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 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.
120 characters isn't enough to explain it.
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.
Will I retire or break 10K?
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
---
Unto the land of the dead shalt thou be sent at last.
Surely thou shalt repent of thy cunning.
https://www.accountkiller.com/removal-requested
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.
I must admit I've got dreams of coding faster strcmp's, though.
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?
Updated by them in September: http://support.intel.com/support/processors/pentiu miii/intnotes.htm#Processor%20Updates .
bug.gd: error search engine. Humanity working together to solve all errors.
Using BIOS Update, is it possible to remove or alter the processor serial number on Pentium 3 chips?
Inquiring minds want to know...
All about me
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.
BOSTON SUCKS!
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.
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...
"Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
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.
/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.
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
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
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.
The Economics of Website Security
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
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Could the microcode contain instructions to unlock or change the multiplier on Intel CPUs? O/Cers want to know.
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.
The enemies of Democracy are
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. :)
The anti-salmon
And processors are usually categorized by bits per instruction.
RISC processors, perhaps. But CISC 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 width.
Will I retire or break 10K?
[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
Liquor
Sanity is a highly overrated commodity.
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 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.
11*43+456^2
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.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...
Choice of masters is not freedom.
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....
Papa Legba come and open the gate
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 truth shall set you free!
The truth shall set you free!
The most interesting, funny, etc. BIOS Update hack.
A monkey is doing the real work for me.
Pentium Pro is not IA-32 (it is according to byte). Ppro has 36 bytes alloc'd for each register.
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.
The truth shall set you free!
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!
Knowledge is power. Knowledge shared is power multiplied.
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!
Knowledge is power. Knowledge shared is power multiplied.
<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.
Now I can talk to the midichlorians who live inside my CPU...
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
Respond to s
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?
In Murphy We Turst
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.
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?
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?"
All about me
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...
Obliteracy: Words with explosions
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" (I think that's the URL).
~ Give me 101 plastic soldiers, and I will conquer the world.
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.
If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
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 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>
Will I retire or break 10K?
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."
Will I retire or break 10K?
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 ;)
"Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
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.
Not a discussion of motherboards. It's a discussion of processors. Actual upgradeable microcode on the CPU itself.
I send you this message in order to have your advice.
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.
The anti-salmon
People releasing harmful microcode. Hmmm. Nope. Don't think I've got to worry about buggy processors . . .
I've got an Athlon.
...
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...
Black and grey are both shades of white.
Seems like the Byte editor never tried an 2.3 or 2.4 kernel. /dev/cpu/microcode option is there for a long time now.
The
--
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
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.
// what do you mean that was the only copy...
Thought I would mention that, since last summer, you can update the microcode of your P6 family chip under Linux. The utility is here. 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.
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
In fact those instructions are lost when the CPU when there's a reset/restart (which is why it is reloaded by the BIOS at startup). At worst it could make a bad hangup... which there are easier ways to do.
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..
Do not forget that chips contains bugs and sometimes, you can fix "timing" bugs by using "slow" operation in the microcode.
So squeeze performances out of the microcode? Well, thank you but NO!
OTOH maybe there is a way to add new instructions which could trigger errors only if you effectively use those new instructions...
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 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.
Don't you think he was being ironic?
This sig under construction. Please check back later.
http://freshmeat.net/projects/intelp6microcodeupda teutility/
cannot run it on my lowly pentium though...
And intel doesn't send out any errata/changelog with their updates to microcode
OK, first off, no, I'm not worried about microcode virii. (This may be flamebait otherwise) What's interesting though is how some people are pointing out that an update containing malaciousness wouldn't be a problem since it would be erased on reboot, but then no one is mentioning that it would be re-loaded also. If somehow a person were to make a microcode virus and it got flashed in as a new update (very unlikely) what would then happen? Your 'puter wouldn't work, so you'd reset - knowing that this would clear the micro-code and allow it to be re-loaded. On boot, your 'puter goes to load it's micro-code, and loads the current set of instructions, the malicious one you placed on there. Unless you happened to have a flash utility that would restore your old instructions before the new ones are loaded - your 'puter would now be useless, at least the moboard. (That is where the instructions are stored right? I don't know alot about the low-level goings-on of 'puters like this, but that's what I gleaned from the article and other posts.)
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?
Main Entry: sarcastic /-ti-k(&-)lE/ adverb
Pronunciation: sär-'kas-tik
Function: adjective
Date: 1695
1 : having the character of sarcasm
2 : given to the use of sarcasm : CAUSTIC - sarcastically
synonyms SARCASTIC, SATIRIC, IRONIC, SARDONIC mean marked by bitterness and a power or will to cut or sting. SARCASTIC implies an intentional inflicting of pain by deriding, taunting, or ridiculing . SATIRIC implies that the intent of the ridiculing is censure and reprobation . IRONIC implies an attempt to be amusing or provocative by saying usually the opposite of what is meant . SARDONIC implies scorn, mockery, or derision that is manifested by either verbal or facial expression .
According to that dictionary, there doesn't seem to be that much difference between sarcastic and ironic. Still, it seems to me that ironic is more relevant in this case.
This sig under construction. Please check back later.
11*43+456^2
Fuck off Nigger
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*
Obliteracy: Words with explosions
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 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.