Paul CPU Microcode Question

Discussion in 'Asus' started by Ron Reaugh, Sep 2, 2004.

  1. Ron Reaugh

    Ron Reaugh Guest

    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

    Does which microcode version page?/module? gets loaded also depend on 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?

    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.
    Ron Reaugh, Sep 2, 2004
    1. Advertisements

  2. Ron Reaugh

    Paul Guest

    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.
    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
    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 ?
    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:

    Paul, Sep 2, 2004
    1. Advertisements

  3. Ron Reaugh

    P2B Guest

    Not encrypted AFAIK, but otherwise correct.
    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. 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, Sep 2, 2004
  4. Ron Reaugh

    Ron Reaugh Guest

    Way more than I do and more than anyone else that has stepped forward so

    I figured that angle but MS+Intel have now brought the issue front and
    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.
    I am unaware of any MS KB articles on this issue.
    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
    ( 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.
    Ron Reaugh, Sep 2, 2004
  5. Ron Reaugh

    P2B Guest

    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.
    My test results suggest a reload is indeed performed, but obviously are
    only valid for the Asus Award BIOS tested.
    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, Sep 2, 2004
  6. Ron Reaugh

    Ron Reaugh Guest

    Ron Reaugh, Sep 2, 2004
  7. Ron Reaugh

    Ron Reaugh Guest

    Ron Reaugh, Sep 2, 2004
  8. Ron Reaugh

    Ron Reaugh Guest

    Definitely heavily encrypted...think about it.
    Never seen that reported anywhere. Can you sight anywhere that such a
    message is documented or cited?
    Very cool...thanks.
    Ron Reaugh, Sep 2, 2004
  9. Ron Reaugh

    Ron Reaugh Guest

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

    Never has and never will but it might slow hacking initially.
    Now do you see why the microcode is already have thought
    about it.
    Ron Reaugh, Sep 2, 2004
  10. Ron Reaugh

    Paul Guest

    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 :) (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

    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, Sep 2, 2004
  11. 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
    Barry Watzman, Sep 2, 2004
  12. Ron Reaugh

    Ron Reaugh Guest

    No, the CPU does NOT lose power during a reset button cycle.
    That's a good assumption.

    What message exactly? Can you cite an example?
    Which message?
    Ron Reaugh, Sep 2, 2004
  13. Ron Reaugh

    P2B Guest

    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.
    Probably, but my guess is it means no more than "the header includes a
    checksum" :)

    P2B, Sep 2, 2004
  14. Ron Reaugh

    Ron Reaugh Guest

    No, I've seen the fact that it IS encrypted documented somewhere and above
    "An encoding scheme also guards against tampering..".
    Ron Reaugh, Sep 2, 2004
  15. Ron Reaugh

    P2B Guest

    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.
    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:

    (only available in german)
    P2B, Sep 3, 2004
  16. Ron Reaugh

    P2B Guest

    That would be an interesting read, if you can find it again.

    and above
    P2B, Sep 3, 2004
  17. Ron Reaugh

    Donald White Guest

    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, Sep 3, 2004
  18. Ron Reaugh

    Paul Guest

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

    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, Sep 3, 2004
  19. Ron Reaugh

    Egil Solberg Guest

    I remember a lot of post like this from P3V4X owners at one time, and was
    solved with latest beta BIOS then.
    Egil Solberg, Sep 3, 2004
  20. Ron Reaugh

    Ron Reaugh Guest

    Ron Reaugh, Sep 3, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.