Paul CPU Microcode Question

  • Thread starter Thread starter Ron Reaugh
  • Start date Start date
R

Ron Reaugh

Ok so during BIOS init a Intel CPU has encrypted microcode loaded into the
CPU. That microcode depends on exactly which CPU model is present.

Does that microcode load happen during Ctl-Alt-Del?

Does that microcode load happen during reset button or only at power-up
time?

Does which microcode version page?/module? gets loaded also depend on CPU
stepping?

Does the BIOS that one flashes to the mobo contain all the possible CPU
microcode pages?/modules? for all the possible CPUs and all the steppings
that the particular motherboard can handle OR does it depend on what CPU is
in the mobo's socket when the BIOS is flashed?

Depending on the answer, might it be a requirement to flash a mobo BIOS
each time the CPU is changed and/or might that imply that there are a whole
bunch of different microcode pages?/modules? within the BIOS and accounting
for much of its size?

With respect to the SP2+Prescott+865/875 issue the reason for the ambiguity
about whether CPU revision=7 or =8 is needed has been apparently answered.
=7 is sufficient for Prescotts of a given set of steppings and =8 is
sufficent for other steppings of Prescott CPUs. =9 microcode is present in
some BIOSs.
 
Answers inline:

First of all, it should be pretty obvious I don't know very much about
this topic. Otherwise I would have "spilled the beans" by now.
I believe in a previous search, I couldn't find any Intel docs on
the subject, and that is how it should be anyway :-) Less knowledge
in the hands of hackers, means less problems for end users.
Ok so during BIOS init a Intel CPU has encrypted microcode loaded into the
CPU. That microcode depends on exactly which CPU model is present.
Click to expand...
All I can remember, is someone suggesting you could blindly load
one 2KB segment after another, and microcode segments that didn't
match would be ignored. Based on the fact that the Intel utility
returns a "CPU_version" field, that corresponds to the revision
level of the microcode, in fact proves there is more to the
interface than complete blindness. It does imply, that if the BIOS
loads revision "N", the update.sys could check the Windows bundled
revision and load it, if the revision is a later one. I have no
idea as to exactly when the processor stops accepting candidates for
"final microcode".
Does that microcode load happen during Ctl-Alt-Del?

Does that microcode load happen during reset button or only at power-up
time?
Click to expand...
My guess would be that, while a reset wouldn't necessarily wipe
out the microstore, a prudent BIOS algorithm would be to reload it.
Does which microcode version page?/module? gets loaded also depend on CPU
stepping?
Click to expand...
No concrete documentation - just a lot of unsubstantiated guesses.
A typical Asus BIOS has (8) 2KB microcode segments, so any algorithm
you can think of is feasible. I have seen BIOS with more than that.
Does the BIOS that one flashes to the mobo contain all the possible CPU
microcode pages?/modules? for all the possible CPUs and all the steppings
that the particular motherboard can handle OR does it depend on what CPU is
in the mobo's socket when the BIOS is flashed?
Click to expand...
The microcode segments provided should be cumulative, unless the flash
EEPROM is running out of space. I think the practice is to nuke the
motherboard logo, to make room, if new code takes too much space.
As you use later BIOS releases, the microcode file in the BIOS should
grow.
Depending on the answer, might it be a requirement to flash a mobo BIOS
each time the CPU is changed and/or might that imply that there are a whole
bunch of different microcode pages?/modules? within the BIOS and accounting
for much of its size?
Click to expand...
Microcode takes a tiny portion of the BIOS. The revision of BIOS required,
should only have to be high enough, to get microcode when the processor
is introduced. If you purchase a processor that was just recently
introduced by Intel, then flashing the BIOS can be necessary just to get
code to deal with the new processor - for example, the bug where a
3.2GHz Prescott is recognized as a 2.8GHz, requires code to read the
platform bit and set up the processor some how, based on that bit. That
is not microcode, but a difference in processor interface itself. So,
getting that piece of code is one part of the solution, and the
microcode in that case, was introduced before that bug was known
and fixed.

I have seen BIOS, with two microcode segments for the same family
code, but different revision levels. Either that is a packaging error,
or implies there is some finer granularity in the microcode than I
know about. When that happens, generally it only happens for one
particular family code, and not all of them, which suggests it could
be clumsy packaging.
With respect to the SP2+Prescott+865/875 issue the reason for the ambiguity
about whether CPU revision=7 or =8 is needed has been apparently answered.
=7 is sufficient for Prescotts of a given set of steppings and =8 is
sufficent for other steppings of Prescott CPUs. =9 microcode is present in
some BIOSs.
Click to expand...

Considering the number of processors out there, isn't it time
Microsoft issued their own info, as to exactly what is required ?
Experimenting one processor type at a time, is a lot of unnecessary
work. Has Microsoft admitted to the problem, or is the Cari
"community" entry in the KB the only evidence that the problem is
known ?

While we are on the topic of microcode, I notice that my tool set
doesn't work properly with the new P5AD2 board with 1MB flash chip.
So, it will be a little difficult to provide this info for the
latest 915/925 boards. A guess would be that the microcode file
format in the new BIOS has changed again. Here is a previous
effort to document it:

http://groups.google.com/[email protected]

Paul
 
Ron said:
Ok so during BIOS init a Intel CPU has encrypted microcode loaded into the
CPU. That microcode depends on exactly which CPU model is present.
Click to expand...

Not encrypted AFAIK, but otherwise correct.
Does that microcode load happen during Ctl-Alt-Del?
Yes.

Does that microcode load happen during reset button or only at power-up
time?
Both.

Does which microcode version page?/module? gets loaded also depend on CPU
stepping?
Click to expand...

Yes, indirectly. Microcode updates are indexed by CPUID string, which
always changes for different steppings of the same family and model of CPU.
Does the BIOS that one flashes to the mobo contain all the possible CPU
microcode pages?/modules? for all the possible CPUs and all the steppings
that the particular motherboard can handle OR does it depend on what CPU is
in the mobo's socket when the BIOS is flashed?
Click to expand...

The BIOS typically contains microcode updates for all available CPUs
supported by the board when the BIOS was released. All updates are
flashed to the BIOS chip regardless of currently installed CPU.
Depending on the answer, might it be a requirement to flash a mobo BIOS
each time the CPU is changed and/or might that imply that there are a whole
bunch of different microcode pages?/modules? within the BIOS and accounting
for much of its size?
Click to expand...

Most BIOSes will display an error message if the BIOS does not include
microcode for the current CPU. This message is informational, i.e. does
not prevent the system from booting the operating system, and is usually
harmless unless the CPU has critical errata (rare) and the OS does not
supply microcode.

BTW, my answers to the above questions regarding when the updates are
loaded were determined by deliberately removing microcode for CPUID x6B4
from a BIOS, flashing it to a system with an x6B4 CPU, then restarting
with power on, reset, and Ctl-Alt-Del - and observing that the microcode
update failure message was displayed in all 3 cases.

Microcode updates are 2KB each and are stored compressed (typically
~50%) in a single file within the BIOS. As an example, a typical Asus
P2B BIOS contains ~20 updates and accounts for ~20KB of the total BIOS size.

P2B
 
Paul said:
Answers inline:

First of all, it should be pretty obvious I don't know very much about
this topic.
Click to expand...

Way more than I do and more than anyone else that has stepped forward so
far.
Otherwise I would have "spilled the beans" by now.
I believe in a previous search, I couldn't find any Intel docs on
the subject, and that is how it should be anyway :-) Less knowledge
in the hands of hackers, means less problems for end users.
Click to expand...


I figured that angle but MS+Intel have now brought the issue front and
center.
All I can remember, is someone suggesting you could blindly load
one 2KB segment after another, and microcode segments that didn't
match would be ignored. Based on the fact that the Intel utility
returns a "CPU_version" field, that corresponds to the revision
level of the microcode, in fact proves there is more to the
interface than complete blindness. It does imply, that if the BIOS
loads revision "N", the update.sys could check the Windows bundled
revision and load it, if the revision is a later one. I have no
idea as to exactly when the processor stops accepting candidates for
"final microcode".

My guess would be that, while a reset wouldn't necessarily wipe
out the microstore, a prudent BIOS algorithm would be to reload it.

No concrete documentation - just a lot of unsubstantiated guesses.
A typical Asus BIOS has (8) 2KB microcode segments, so any algorithm
you can think of is feasible. I have seen BIOS with more than that.

The microcode segments provided should be cumulative, unless the flash
EEPROM is running out of space. I think the practice is to nuke the
motherboard logo, to make room, if new code takes too much space.
As you use later BIOS releases, the microcode file in the BIOS should
grow.

Microcode takes a tiny portion of the BIOS. The revision of BIOS required,
should only have to be high enough, to get microcode when the processor
is introduced. If you purchase a processor that was just recently
introduced by Intel, then flashing the BIOS can be necessary just to get
code to deal with the new processor - for example, the bug where a
3.2GHz Prescott is recognized as a 2.8GHz, requires code to read the
platform bit and set up the processor some how, based on that bit. That
is not microcode, but a difference in processor interface itself. So,
getting that piece of code is one part of the solution, and the
microcode in that case, was introduced before that bug was known
and fixed.

I have seen BIOS, with two microcode segments for the same family
code, but different revision levels. Either that is a packaging error,
or implies there is some finer granularity in the microcode than I
know about. When that happens, generally it only happens for one
particular family code, and not all of them, which suggests it could
be clumsy packaging.


Considering the number of processors out there, isn't it time
Microsoft issued their own info, as to exactly what is required ?
Click to expand...

Somebody obviously needs to. The Prescott+865/875+SP2 issue was known by
mid-June and likely much earlier but the mobo mfgs seem to have been caught
by surprise as did MS so appear. That's the part I can't figure.
Experimenting one processor type at a time, is a lot of unnecessary
work. Has Microsoft admitted to the problem, or is the Cari
"community" entry in the KB
Click to expand...

I am unaware of any MS KB articles on this issue.
the only evidence that the problem is
known ?
Click to expand...

Cari is a connected MVP apparently. It was very curious in that the
carefully worded extreme minimum was posted in the microsoft.public.....
NGs AND they never answered most all my questions...ergo I end up here
bugging you as no one else is talkin. My opening post here on this issue
was also posted to a number of other NGs and basically your answer is the
only one with any content.

Cari's posts(thread) did point to some Web forums where Cari did post a more
complete version of what MS & Intel had said in an email(still minimal). So
to that extent MS has recognized the issue. MS has NOT admitted that the
real bug is apparently in their SP2 version of update.sys as they only talk
about deficient mobo BIOS microcode but also quietly mention that renaming
update.sys fixes the issue for Prescotts regardless of microcode version and
then even more quietly mentioning that if you want to use SP1's update.sys
that works too.

Since Cari's posts another MS MVP(cquirke
(http://cquirke.mvps.org/sp2intel.htm)) has some threads on the issue
including some details about the stepping vs microcode needed for
Prescott+SP2. None respond to follow-up questions. It was fairly clear
that Cari was at her peter principle limit on the issue but cquirke either
has a fast learning curve and good learning resources OR already had a
considerable knowledge in this arena.
 
Paul said:
Answers inline:

First of all, it should be pretty obvious I don't know very much about
this topic. Otherwise I would have "spilled the beans" by now.
I believe in a previous search, I couldn't find any Intel docs on
the subject, and that is how it should be anyway :-) Less knowledge
in the hands of hackers, means less problems for end users.
Click to expand...

I'm astounded at your advocating security by obscurity. It doesn't work.

The determined hacker (malicious or merely curious) will gain the
knowledge through reverse engineering anyway, and use it as he sees fit.
Nobody benefits from lack of documentation, except perhaps the vendors
of proprietary systems.
All I can remember, is someone suggesting you could blindly load
one 2KB segment after another, and microcode segments that didn't
match would be ignored. Based on the fact that the Intel utility
returns a "CPU_version" field, that corresponds to the revision
level of the microcode, in fact proves there is more to the
interface than complete blindness. It does imply, that if the BIOS
loads revision "N", the update.sys could check the Windows bundled
revision and load it, if the revision is a later one. I have no
idea as to exactly when the processor stops accepting candidates for
"final microcode".



My guess would be that, while a reset wouldn't necessarily wipe
out the microstore, a prudent BIOS algorithm would be to reload it.
Click to expand...

My test results suggest a reload is indeed performed, but obviously are
only valid for the Asus Award BIOS tested.
No concrete documentation - just a lot of unsubstantiated guesses.
A typical Asus BIOS has (8) 2KB microcode segments, so any algorithm
you can think of is feasible. I have seen BIOS with more than that.
Click to expand...

Given the observed behavior, and the reverse engineered microcode file
documentation available, it seems highly unlikely the algorithm is other
than query CPUID, load corresponding microcode if present, or complain
microcode is unavailable.
 
P2B said:
Not encrypted AFAIK, but otherwise correct.
Click to expand...

Definitely heavily encrypted...think about it.
Yes, indirectly. Microcode updates are indexed by CPUID string, which
always changes for different steppings of the same family and model of CPU.

The BIOS typically contains microcode updates for all available CPUs
supported by the board when the BIOS was released. All updates are
flashed to the BIOS chip regardless of currently installed CPU.


Most BIOSes will display an error message if the BIOS does not include
microcode for the current CPU.
Click to expand...

Never seen that reported anywhere. Can you sight anywhere that such a
message is documented or cited?
This message is informational, i.e. does
not prevent the system from booting the operating system, and is usually
harmless unless the CPU has critical errata (rare) and the OS does not
supply microcode.

BTW, my answers to the above questions regarding when the updates are
loaded were determined by deliberately removing microcode for CPUID x6B4
from a BIOS, flashing it to a system with an x6B4 CPU, then restarting
with power on, reset, and Ctl-Alt-Del - and observing that the microcode
update failure message was displayed in all 3 cases.
Click to expand...

Very cool...thanks.
 
Come on now..we got two posters...where are the rest??

P2B said:
I'm astounded at your advocating security by obscurity. It doesn't work.
Click to expand...

Never has and never will but it might slow hacking initially.
The determined hacker (malicious or merely curious) will gain the
knowledge through reverse engineering anyway, and use it as he sees fit.
Click to expand...

Now do you see why the microcode is encrypted....you already have thought
about it.
 
P2B said:
I'm astounded at your advocating security by obscurity. It doesn't work.

The determined hacker (malicious or merely curious) will gain the
knowledge through reverse engineering anyway, and use it as he sees fit.
Nobody benefits from lack of documentation, except perhaps the vendors
of proprietary systems.
Click to expand...
I guess my perspective on this, is the microcode feature is a private
interface. (Unless you feel that mere mortals can identify bugs in the
internal design of a modern microprocessor, propose and execute a bug
fix in microcode, and then distribute the result.)

About the only documentation should be the BIOS writer's
info on how to load the microcode (which I found - a bonus :-)

http://www.intel.com/design/pentiumii/manuals/24319202.pdf (pg.305)

"The microcode update is a data block that is exactly 2048 bytes
in length. The initial 48 bytes of the update contain a header
with information used to identify the update. The update header
and its reserved fields are interpreted by software based upon
the header version. The initial version of the header is 00000001h.
An encoding scheme also guards against tampering of the update data
and provides a means for determining the authenticity of any given
update."

So, there is some kind of encoding/encryption, and being a private
interface, no need to say what algorithm is being used.

I think the above section will make Ron real happy :-)

Paul
 
Not sure if microcode gets loaded during Ctrl-Alt-Delete, but it
probably not, as the CPU is not reset (on most motherboards, anyway).
But it might vary by motherboard and/or bios (it's possible to reset the
CPU on ctrl-alt-del, but usually it's not done).

Teh reset button and power on are electically identical, so the
microcode is reloaded if the reset button is pressed.

The microcode that gets loaded can depend on the stepping, but doesn't
necessarily. As you yourself noted, sometimes different steppings use
the same microcode, sometimes they use different microcodes.

The bios contains all microcodes that the motherboard mfgr. chose to
support in that version of the bios. It's fixed for any bios version
and does not depend on what CPU is on the board when the bios is flashed.

If you upgrade to a CPU which is newer than the BIOS version currently
on the motherboard, you should download and reflash the latest bios. It
may contain microcode used by the newer CPU that was not present in the
older bios.

If the microcode for the CPU in question is wrong or missing, you get an
error message during boot, but the CPU continues and runs, without the
microcode update (using the microcode in the CPU; what really gets
loaded is not base microcode, but rather a microcode UPDATE (patches)).
Unfortunately, most people don't pay attention to or understand this
message.
 
Barry Watzman said:
Not sure if microcode gets loaded during Ctrl-Alt-Delete, but it
probably not, as the CPU is not reset (on most motherboards, anyway).
But it might vary by motherboard and/or bios (it's possible to reset the
CPU on ctrl-alt-del, but usually it's not done).

Teh reset button and power on are electically identical,
Click to expand...

No, the CPU does NOT lose power during a reset button cycle.
so the
microcode is reloaded if the reset button is pressed.
Click to expand...

That's a good assumption.
The microcode that gets loaded can depend on the stepping, but doesn't
necessarily. As you yourself noted, sometimes different steppings use
the same microcode, sometimes they use different microcodes.

The bios contains all microcodes that the motherboard mfgr. chose to
support in that version of the bios. It's fixed for any bios version
and does not depend on what CPU is on the board when the bios is flashed.

If you upgrade to a CPU which is newer than the BIOS version currently
on the motherboard, you should download and reflash the latest bios. It
may contain microcode used by the newer CPU that was not present in the
older bios.

If the microcode for the CPU in question is wrong or missing, you get an
error message during boot,
Click to expand...


What message exactly? Can you cite an example?
but the CPU continues and runs, without the
microcode update (using the microcode in the CPU; what really gets
loaded is not base microcode, but rather a microcode UPDATE (patches)).
Unfortunately, most people don't pay attention to or understand this
message.
Click to expand...

Which message?
 
Paul said:
I guess my perspective on this, is the microcode feature is a private
interface. (Unless you feel that mere mortals can identify bugs in the
internal design of a modern microprocessor, propose and execute a bug
fix in microcode, and then distribute the result.)
Click to expand...

In this instance, fair enough - however I interpreted "Less knowledge in
the hands of hackers, means less problems for end users" as a general
statement, one with which I strongly disagree.
About the only documentation should be the BIOS writer's
info on how to load the microcode (which I found - a bonus :-)

http://www.intel.com/design/pentiumii/manuals/24319202.pdf (pg.305)

"The microcode update is a data block that is exactly 2048 bytes
in length. The initial 48 bytes of the update contain a header
with information used to identify the update. The update header
and its reserved fields are interpreted by software based upon
the header version. The initial version of the header is 00000001h.
An encoding scheme also guards against tampering of the update data
and provides a means for determining the authenticity of any given
update."

So, there is some kind of encoding/encryption, and being a private
interface, no need to say what algorithm is being used.

I think the above section will make Ron real happy :-)
Click to expand...

Probably, but my guess is it means no more than "the header includes a
checksum" :-)

P2B
 
Probably, but my guess is it means no more than "the header includes a
checksum" :-)
Click to expand...

No, I've seen the fact that it IS encrypted documented somewhere and above
"An encoding scheme also guards against tampering..".
 
Ron said:
Definitely heavily encrypted...think about it.
Click to expand...

I would definitely expect a checksum to verify integrity, but since
microcode format and content is one of a CPU manufacturer's most closely
guarded secrets I'm not sure what value encryption would add.

The point is moot, really - the data is meaningless unless you can
interpret it, which is not possible without documentation of the
language and format used.
Never seen that reported anywhere. Can you sight anywhere that such a
message is documented or cited?
Click to expand...

I've certainly answered many queries of the form "what does this message
mean, and how do I make it go away" on this and other newsgroups, but
the motherboard manufacturers typically don't document it - however
Googling for "BIOS update data incorrect" will turn up many references,
including an Asus FAQ:

http://www.asuscom.de/support/FAQ/faq014_cpu_id.htm

(only available in german)
 
P2B said:
The BIOS typically contains microcode updates for all available CPUs ^^^^^^^^^
supported by the board when the BIOS was released. All updates are
flashed to the BIOS chip regardless of currently installed CPU.
Click to expand...

I have an old IBM Netfinity 3000 system which must be flashed after
every CPU change or the BIOS complains about no microcode available.
The typical case is as you state.
 
Donald White said:
I have an old IBM Netfinity 3000 system which must be flashed after
every CPU change or the BIOS complains about no microcode available.
The typical case is as you state.
Click to expand...

And, that will be done using the INT15 hook described in the Intel
document.

Now I understand why the Asus BIOS has both microcode segments
resident in the BIOS and also slots for an INT15 hook update of
the microcode. The slots aren't there as caches, they are there
to support the Intel design intent, of being able to use INT15
updating of the microcode (D042).

That gives me new hope that the CTMC program will be able to
update both AMI and Award BIOS with new microcode. To verify
that the AMI could be updated with CTMC, all that is required
is to flash the BIOS, reboot the computer, back up the BIOS,
and compare the two BIOS files. If a 2KB segment in the code
is different between the two images, it means the INT15
mechanism is being used by the BIOS itself. That raises the
odds of CTMC being able to solve the SP2 problem, without
having to flash the whole BIOS.

Paul
 
P2B said:
I've certainly answered many queries of the form "what does this
message mean, and how do I make it go away" on this and other
newsgroups, but the motherboard manufacturers typically don't
document it - however Googling for "BIOS update data incorrect" will
turn up many references, including an Asus FAQ:

http://www.asuscom.de/support/FAQ/faq014_cpu_id.htm

(only available in german)
Click to expand...

I remember a lot of post like this from P3V4X owners at one time, and was
solved with latest beta BIOS then.
 
Back
Top