Will vendor locking CPU’s become more common?
We’ve recently seen evidence of UEFI based malware that can survive an OS reinstall. Technology that establishes a secure root of trust and an impenetrable chain of trust is essential to prevent such attacks. Some modern CPU’s such as AMD Epyc and AMD’s Ryzen Pro CPUs offer a feature called Platform Secure Boot which is roughly equivalent to Intel Boot Guard with one key difference – in Intel’s case, the root of trust is extended only to the PCH, in AMD’s it extends to the CPU. Depending on how this feature is implemented this can sometimes have the unfortunate effect of permanently locking a CPU to particular motherboards (most likely to a brand of motherboard).
Can installing a CPU in a motherboard prevent its install in other motherboards?
In some instances, it can. Extending the root of trust to the CPU means it’s a touch more secure however some vendors have taken this to an extreme, permanently locking a CPU to certain motherboards. This feature has been used recently in quite a few servers from various manufacturers and one Redditor recently reported that they were prompted on a Lenovo Desktop. By the sounds in some Dell PowerEdge servers, the process of simply installing a CPU can lock it to the platform.
This has the implication that when buying a second-hand CPU or even if simply testing a CPU in a particular motherboard one risks ending up with a CPU locked to a particular platform.
Thankfully STH reports that HPE takes a different approach as opposed to permanently blowing fuses on the CPU which performs a similar function without locking a CPU to a particular platform permanently. So not all manufacturers are going down this rather questionable road.
Do we really need to permanently lock a CPU to a platform to extend the root of trust?
Quite frankly no. Doing so is unnecessary and ridiculous. Instead of hard burning fuses, keys or hashes of the firmware could be stored in some flash memory on the CPU. If they don’t match then the user could be alerted and asked if they’d like to update stored security data. This could even be locked behind a physical jumper on the motherboard to prevent software tampering without user intervention, requiring a password/key whose hash will be stored in the security processor (with limits/delays between retries) would also restrict such changes to authenticated users. Of course, a solution such as this adds complexity but it also maintains the generally expected capability that a CPU can be safely moved between compatible platforms.
Will we see more of this in future?
I think it’s reasonable to expect more of this to occur in servers and workstations, possibly with certain OEM-only CPUs but probably less likely with custom PC components as I can’t see that particular crowd particularly people such as enthusiasts, overclockers, reviewers etc. taking too kindly to their CPUs being permanent to a given platform. If we start seeing it implemented there I expect severe backlash.
Final Words
Whilst security is important, I feel that it’s something that needs to be tackled in a way that allows the user to decide what risks they are or aren’t willing to take. It’s insane to permanently lock a CPU to a device without a prompt or with a simply Y/N prompt at every boot (I’m sure we can all imagine the less tech-savvy user blindly hitting “Y”). Such a feature the user should have to manually select and enable and there should be multiple prompts detailing the implications of such a decision. If HPE can implement alternate approaches that they’re comfortable with which do not permanently bind a CPU to a platform then I’m sure other vendors can also.
Security features should be used to improve security, not as a tool to inhibit the resale of secondhand components and potentially contribute to eWaste if users assume a CPU is dead when really it’s just locked to a particular platform.