AMD to Substantially Increase Microcode Size For Future CPUs

News
By
published

AMD's Zen 5 CPUs could feature 32KB microcode.

AMD
(Image credit: AMD)

AMD's future microprocessors could increase their microcode size by over two times compared to existing AMD CPUs, according to a new Linux patch spotted by Phoronix. The increased microcode size may suggest that AMD's upcoming processors based on the Zen 5 microarchitecture and its successors will support more complex instructions or will be able to add new features after release — or maybe AMD just wants to ensure that it can update microcodes in a more thorough manner. 

The maximum microcode patch size for AMD CPUs that the Linux kernel currently supports is 12KB (three times the Linux kernel page size of 4096 bytes). The latest patch released by AMD for future CPUs (most likely those based on Zen 5, or perhaps its successors) indicates that microcode size could increase all the way to 32KB — or eight times the Linux kernel page size.  

"Future AMD CPUs will have microcode patches that exceed the current limit of three 4K pages," a statement by AMD reads. "Increase substantially to avoid future size increases."

The increased microcode patch size does not necessarily mean that microcode of AMD's Zen 5 CPUs will be over 2.6 times larger compared to that of AMD's Zen 4 processors. Nonetheless, it points to the fact that it is going to be larger.

CPU microcode is a low-level code that defines how a CPU operates. To a large degree, microcode is a step-by-step guide for how the CPU performs each machine code instruction: it takes higher-level machine code instructions and breaks them down into simpler hardware-level instructions that the CPU can execute. CPU microcode can often be updated, enabling processor developers to fix bugs or security vulnerabilities in the CPU after it has been deployed.

Microcode allows a CPU to handle more complex instructions that would be hard or inefficient to implement directly in hardware. Therefore, the more complex the instruction set, the more complex microcode gets. Hence, if AMD is to implement complex new instruction set extensions into its Zen 5-based products and its successors, it needs to expand its microcode size.

Another reason to increase CPU microcode size is that AMD may anticipate adding new features or capabilities (instructions, optimizations, hardware bug fixes, security enhancements, etc.), and wants to do so without needing to redesign the entire CPU — which is prohibitively costly on the current and upcoming process technologies.

(Image credit: AMD)
Anton Shilov
Anton Shilov
Contributing Writer

Anton Shilov is a contributing writer at Tom’s Hardware. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

See more CPUs News
22 Comments Comment from the forums
  • Zaranthos
    Plenty of room for future malware to be installed?
    Reply
  • citral23
    Zaranthos said:
    Plenty of room for future malware to be installed?

    How exactly?
    Reply
  • bit_user
    Zaranthos said:
    Plenty of room for future malware to be installed?
    If a program or hacker managed to update the microcode in your CPU, it's game over. Even with the current size limits.

    Microcode loading normally happens rather early in the boot sequence and would require root/admin privileges, at minimum. I could believe you can't even do it past a certain point.
    Reply
  • rluker5
    citral23 said:
    How exactly?
    Maybe if somebody found a way to alter the C:>Windows>System32>mcupdate_AuthenticAMD.dll file that rewrites the microcode your system is using at windows boot?

    I've removed the Intel equivalent to get around microcode security updates in the past by changing the owner of the file and moving it. But it has been around since a little after Spectre at least and has been secure all that time AFAIK.

    Edit: One way you can check if you are having your microcode changed by windows is to see what your bios says, then what HWinfo64 says. If they are different then Windows is changing it. When I moved said file then HWinfo64 agreed with my bios and I got my pre mitigation performance back, at the expense of security ofc. If I wanted the security back I just moved the file back to it's original place. This might be handy for bugs? I personally stopped moving the file when I moved on from my old 5775c so it has been a while.
    Reply
  • bit_user
    rluker5 said:
    Maybe if somebody found a way to alter the C:>Windows>System32>mcupdate_AuthenticAMD.dll file that rewrites the microcode your system is using at windows boot?
    Yeah, but if a hacker gets root, you're hosed.

    AFAIK, microcode updates aren't persisted in the CPU across boots, so it's not a place where someone could hide a root kit. Therefore, it's no more special than tons of other exploits someone could do with admin privileges.
    Reply
  • rluker5
    bit_user said:
    Yeah, but if a hacker gets root, you're hosed.

    AFAIK, microcode updates aren't persisted in the CPU across boots, so it's not a place where someone could hide a root kit. Therefore, it's no more special than tons of other exploits someone could do with admin privileges.
    You are right that the updates aren't persistent across reboots and don't stick with the CPU in any way other than the current windows session.

    There may be a way to mess with encryption, or disable it by altering the microcode but that is just my conjecture. I don't know anything of how microcode alterations could affect security processes.

    You definitely need admin privileges to change the owner from trustedinstaller, change the permissions and move the file and there are probably a lot of easier ways to snoop or harvest as an admin.

    I mostly brough it up as a possibility, not a viable option.
    That and I did have improved performance with an older microcode with the 5775c vs the ones Windows inserted. I also tested a variety with a 4770k and saw no noticeable improvement with any of them. Perhaps, if sometime in the future, some microcode update came out with a performance regression for some, then reverting the microcode to the bios version would be useful again. It might even be useful for those with early Alder chips with older bioses to keep their 512 going if an update snatches that away.
    Reply
  • Kamen Rider Blade
    Just one more "Power of 2" & it would've come out to exactly 64 KiB or the size of a "UI16b" integer
    Reply
  • hotaru.hino
    The thing that would strike me as really bad is if the OS blindly trusts any and all microcode updates. That is, if there's no digital signage on the microcode update itself that either the OS or CPU could check, then I'm going to have to face palm really hard.
    Reply
  • jackt
    that zen4c look interesting... when ?
    Reply
  • bit_user
    hotaru.hino said:
    The thing that would strike me as really bad is if the OS blindly trusts any and all microcode updates. That is, if there's no digital signage on the microcode update itself that either the OS or CPU could check, then I'm going to have to face palm really hard.
    I assume the loader does an integrity check on the payload, but that's probably more to protect against unintended corruption.

    They could encrypt it with a key that only the CPU manufacturer knows, and then have the CPU decrypt the microcode as it's loaded, but then if the manufacturer ever went out of business (or just flat out refused to issues microcode fixes for old CPUs, as I think Intel did with some of the side-channel vulnerabilities), that would prevent anyone else from offering their own microcode fixes.
    Reply