Not really. AMD is only selling unlocked CPUs, and the "locking" is done the first time it boots in a given motherboard. So crossing regions wouldn't be any more of an issue in the future than it is now, you "just" need to ensure your motherboard and CPU come bundled together. Or you need to ensure you get an "unlocked" CPU, which is what retailers provide via AMD.
This will greatly complicate the future second-hand market, though. Buying used Epyc CPUs off of ebay in 5 years will become very sketchy for example.
You could have some crude region locking if SGI US signs with a different key than SGI EU, and US servers will only run on 60hz power supplies and EU servers only run on 50hz (some pinball machines use this to reduce transatlantic resale) it's not hard to measure, but it would need an extra power supply pin and a zero crossing circuit. DC systems would have a different signing key. Japanese systems wouldn't be able to move across their 50/60Hz divide, etc.
That only region locks the motherboard. The CPU would only be locked after it has been used in the motherboard, not before, which necessarily means you already have the CPU in question. So there wouldn't be any barrier to CPU movement across regions.
As in for your example there isn't anything stopping you from buying a CPU from anyone, including US retailers, and using it in an SGI EU motherboard. The CPU itself isn't locked when new, this signing key locking isn't baked into the CPU at the factory. It happens when you plop it into the socket & fire it up for the first time.
> As in for your example there isn't anything stopping you from buying a CPU from anyone.
I can't buy a used cpu from an SGI US customer and put it in an SGI EU motherboard. I can buy a new CPU from anyone though, but then I can only sell it in-region.
> I can't buy a used cpu from an SGI US customer and put it in an SGI EU motherboard.
Correct, but that's less a region thing and more this just poisons all used CPUs.
As in you don't even know if an SGI US CPU will work in a different SGI US motherboard. There's no particular reason to assume all SGI US motherboard models will have the same signing key. Within the same model that'd almost certainly be the case, but if it's a different model, especially different chipset, I don't know why they would necessarily strive to keep the key the same across different firmware branches.
> I can buy a new CPU from anyone though, but then I can only sell it in-region.
Er, why? Nothing about this stops you from re-selling CPUs however you want. Or are you still talking about the used market here?
I'm not reselling a cpu without plugging it in and testing it. If it's DOA when my customer got it, and I didn't test it, I need to take it back etc. Of course, if it gets locked when I test it, now it's more likely to be DOA for my customer.
Its not really vendor locking by design. It locks to a signing key. That key COULD be shared between vendors or even a single vendor could have multiple incompatible keys.
It provides a mechanism to prove the entire boot process hasn't been tampered with, but I wish AMD provided a way to run these fused processors in a generic way without the security chain, with it just reporting that there isn't a secure root of trust. However I assume they are afraid of that allowing malicious code to fool deeper parts of the system without the system administrator knowing.
So good for security, but bad for e-waste and second hand sales.
Wouldn’t it make more sense to blow the motherboard rather than the CPU? A compromised CPU without anything connected is pretty useless at boot. The motherboard is what’s connected to all the good stuff.
I think that’s the chicken & egg. If the motherboard was responsible for this, you’re trusting the firmware to validate itself. So this moves the validation a level lower.
It’s an interesting problem. The solution is valid, but it’s unfortunately permanent.
Would be interesting to know whether Dell will use the signing key to unlock the CPU if you ship it to them, or if it's like old motherboards where there is a physical procedure (it was typically to powercycle with a jumper between two pins that shouldn't normally be joined) to reset it, built into the hardware. Seems strange to be able to "brick" a CPU like that.
The article describes the mechanism as programmable fuses; so there is a near-certain chance these are one-time-programmable and can’t be reset. Ever.
(This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)
Fun trivia. The boot loader signing in the raspberry pi works the same way.
Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.
Note - there is even a fuse that when blown, prevents other fuses from being blown!
It’s like an EEPROM that holds major version numbers and debug configurations. If fuse says “major version:20 allow debug: no, allow unsigned: no” and updater is for version 17->18, the user is trying to force a downgrade on a production board. Usually the updater refuses to continue and kernel do the same upon boot. Updater itself is signed and verified so checks are supposed impossible to bypass.
I believe Xbox 360 one was rewritable while Switch one is not. They also require higher voltages than rest of CPU to write. So modders used to modify PCB to block writes or tried to write old values. For Switch they had unrelated nonupdatable boot exploits to bypass signature checks for early batches.
Right, but they weren't asking about those normal fuses, they were asking about the special fuse that disables fuse-blowing.
And the simplest answer is that code could check if the fuses are reading out too early a version and abort. Which you could try to patch around but it won't be easy.
This is what distinguishes a normal iPhone from one that Apple engineers use, as well. If the fuse is blown, as it is in a production device, you can no longer control the boot chain.
> (This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)
this made me think of the pencil trick from the earliest days of socketed athlons. not exactly the same I know.
Is it even possible to unlock it with the signing key? Saying it's fused implies it's a one time thing, doesn't it?
I had the same initial reaction though. It seems like something that makes more sense as a jumper or something that can be reset by jumper so physical access becomes the requirement.
The only reason I can think of to do it as described is to kill the secondary market or, even worse, to maintain a lifetime licensing requirement on the system. If the signing keys can expire like signing certificates I expect step 2 will be custom signed firmware via a cloud portal where no license means no signing. I hope I'm wrong, but that's likely the endgame here.
TLDR; If the signature on the BIOS can expire, it's more nefarious than it sounds IMO.
You have to use on-die fuses to get most of the security benefit vs someone in customs who has a few hours alone with your server, as jumpers can be trivially modified to look like they are set/unset when they are not.
The header pins can be varnished (or other techniques) so they do not conduct, but they still look normal. To set a pin, 36GA wire between the plastic of the header and the PCB would do the trick. If the adversary had a particularly high budget, they could fabricate and install a header that would even pass inspection by a multi-meter's continuity check by making the outer part of the pins be electrically isolated from the inner, except where it contacts the PCB, where the attackers choice of conductivity is made.
I don't think anyone has come up with a good way to downgrade the CPU from secure operation to insecure without also creating a way to bypass it for an attacker. The only way I can think of is if there was a revocation of secure mode that put the CPU serial number on a public list, then after a week, the CPU blew a fuse allowing it to boot in insecure mode. It will allow enterprises to be assured that the computers they are sending all over the globe are untampered, but still allow people who don't care to get them second hand and not be stuck with the rest of the computer. The hard part is making sure the CPU can only blow that fuse after it gets an ack that its been a week. Ideally, there would be some way for the CPU to attest which mode its running in so secondary audits of the CPU's state can be performed.
That makes a lot of sense. I was really only considering things like persistent malware that flashes the BIOS. I still think it'll get abused eventually to devalue the second hand market, but I can see the appeal security wise.
I don't think this is supposed to secure against someone with physical access.
If they have physical access and are replacing the BIOS, they could just replace the CPU at the same time with a fresh unlocked one that will lock itself to the replacement's signing key on first boot.
Why couldn't they have put the key in user-resettable memory which erases the disk encryption key when cleared, like with TPMs for example? It was a poor design to even allow it to be used this way.
This method prevents the user from trying to recover with a backed up encryption key, or booting live media. Instead it makes it clear that this motherboard is compromised and cannot be safely used.
And in the current model, what prevents the user from assuming the processor is dead and replacing it with an unlocked one (which will then presumably become permanently locked to the compromised motherboard)?
If you care about this specific attack scenario then make sure you check the keys with a management tool or something. It's not necessary to make the chip unusable for almost every aftermarket user just to make it a little bit clearer that a compromise has happened in that rare case.
Fair point. Though in many large environments the number of people with access to the IPMI console is greater than the number of people with physical access who can swap out a CPU.
I'm just trying to speculate what might be driving demand for this type of feature, since TPMs already exist.
>So good for security, but bad for e-waste and second hand sales
I concur, but it's true for even consumer devices like smartphones. Once the software updates stop, if security is the key then the devices are e-waste. Many times, I wish there was an International law which forces manufacturers to unlock their device when they stop pushing software updates to their device, so that alternate firmware can be installed. Of course this is just a wishful thinking, even those who abandoned their smartphone segment entirely(MS) didn't do this, So why would those who run profitable business out of planned obsolescence do it?
Instead of grunge everything is covered in RGB LEDs. Literally almost everyone my age has RGB LEDs everywhere. All over their rooms and not to mention keyboards.
The law doesn’t need to be international, only one large enough market needs to do it. The market has to matter enough that the manufacturers won’t just say “screw them” and pull out of it. Then the mechanics are there and everyone benefits even those who live where there is no such law.
Manufacturers already sell unlockable/non-unlockable devices per-market. Not having this be international means they’ll just lock the device where they can.
The UK is currently taking steps towards this - the plans aren't perfect, but will require "security updates until" dates, no default or symmetrically derived passwords, and a vulnerability disclosure programme to be available.
It doesn't go as far as to force unlocking, but requiring transparent disclosure of a committment to security update longevity (like Chromebooks and pixel phones have) is probably the first step along the road to that.
You can get a pretty good idea of how long security updates will be provided already, so does that help almost ever? Like, great, now Motorola has an official promise to do security updates for for 15 months post-launch. If they decide to release a permanently locked phone, the consumer's still getting screwed just as much.
Basically, "doesn't go as far as" sounds like a massive understatement.
> Its not really vendor locking by design. It locks to a signing key.
I see, so it's basically AMD's implementation of Intel Boot Guard, but on servers instead of laptops. On boot, the CPU verifies the BIOS's signature from its OTP memory and refuses to boot if verification fails.
Theoretically, if you move CPUs between different laptops, you'll find the CPUs are locked to its platform as well, but we don't feel it since they are not replaceable, the only visible effect is that the firmware has been locked and you cannot run coreboot.
And now the same thing is coming to servers and it has a bigger visible effect...
No, this won't work if the user is checking the attestation ability of the firmware or system. A similar exploit already exists by just modifying the firmware and expecting the user the just replace the CPU without checking the BIOS.
This is entirely debatable. This is essentially bootguard for socketed CPUs similar to how most laptops behave. For one, it makes fixing the crap that Dell and their contractors write impossible. You cannot replace the bios with coreboot.
For all these features that require blessings, I really liked apple's use of the term notarised. Everyone should call these notarisation features rather than security ones. It's as boring and useless as going to a notary, if you have ever done that.
I managed to get that much from the article but I still feel I'm missing a few pieces here. Are UEFI rootkits an actual concern, like are they common in the wild? Why should the responsibility of detecting them rest with the processor? How is this related to the Secure Encrypted Virtualization?
There have been a couple in the wild, but they aren't super common.
They've become a bigger concern with UEFI since it has a massive attack surface compared to legacy BIOS.
For a processor sitting in AWS / Azure, they want guarantees, and they're the ones EPYCs are designed for.
The responsibility has to rest with the processor, since it's the only thing executing code prior to UEFI. What it's doing is validating that UEFI was cryptographically signed with the correct key prior to running any UEFI code.
When it's first used, it is saving the key for the vendors UEFI implementation and won't allow it to proceed if the root signature ever changes (think something similar to root certs for HTTPS).
It's only relevant to Secure Encrypted Virtualization insofar as they are both implemented inside the PSP which is a separate ARM core that runs at a higher privilege level than the x86 cores (and is the core that actually initializes the x86 cores).
This is how all phones have worked for many years, but apparently it's now becoming a thing in servers too.
> In a multi-processor or multi-core system one CPU is dynamically chosen to be the bootstrap processor (BSP) that runs all of the BIOS and kernel initialization code
These days, the "bootstrap processor" is a separate core that your OS can't see. On Intel it's the IME (running Minix) and on AMD it's the PSP (ARM TrustZone)
> Are UEFI rootkits an actual concern, like are they common in the wild?
If one segment needs to worry about UEFI rootkits, it's cloud vendors. Very dedicated (nation-state sponsored) attackers could burn/use a zero-day hypervisor escape to installs a UEFI rootkit that tampers with the processor's integrated HSM (as said in the article, tampering with it has already happened and the exploits have been patched by AMD). As I understand it, If a vendor uses full memory encryption, the above exploit could lead to decrypting and exfiltrating other customers' data.
The consortium has AMD, Intel, and Microsoft listed as contributors, so even if they didn't initially create the thing, they had a hand in it. The executable format used for UEFI is PE, which is telling.
Not sure why downvoted. I run blobless coreboot for precisely this reason. My only regret is not being able to find newer x86_64 gear that supports it. OTOH you can still buy in-production arm64 boxes that boot with zero blobs (RK3399).
Attacker might flash a tampered BIOS from inside a VM makes total sense. It’s surprising how many SPI ROM there can be in a box, and how basically they’re all waiting there to be exploited.
I am beyond sick of this "security" justification being used for everything. At the end of the day, the only thing really being secured are the greedy vendor's profits.
And this doesn't solve the issue with PSP either. So not much actual progress with security. We need CPUs which do not contain black boxes and allow us to use open source (auditable) firmware (UEFI BIOS).
There are some realistic benefits. If my phone gets stolen, there is no way for it to be wiped and reused without my input. And if it makes it back to me, it is extremely unlikely that it has been loaded with malware which will send off my data when I log in again.
But yes, its really shitty how the downsides end up with the loss of user control and ewaste. Especially when it is possible to design something that is secure and that the user controls.
Really? What phone do you have? A decent number of the recent iPhones have a bootloader exploit now. So there’s no security, just a lot of bitchy software.
Mine is newer than that exploit so no. But also a flaw in the implementation doesn't invalidate the reason for implementing it in the first place. Anti theft features on android and ios have likely saved hundreds of thousands of phones from being stolen, if not millions.
But how often does a server gets stolen from a data center?
It surely makes sense for phones as it makes less profitable to steal them (as you could only sell parts of the phone and even that can be blocked). Maybe even for laptops but not for desktops and servers.
Well, the market is free for someone to offer a processor that doesn't care about "security" (whether it is or isn't the excuse you deem it to be), and we could see if that offering is successful. Maybe there's a new role for something like that. Cursing the situation won't do any good.
Hahahaha, oh, wow, the market is free, hahahaha. Please tell us how to start processor manufacturing business in your own garage, I for one am all ears. Computing is fucked forever, it is in the hands of the powerful few, and Stallman was right all along.
You mean that's going to surely happen, because the server CPU market has traditionally been easy to enter due to low R&D costs, steady avaibility of qualified engineers, cheap manufacturing equipment and customers eager to adopt unknown brands? /s
Well then, maybe you have to live with some inconveniences and higher costs than you would like, because of the natural market dynamics?
You pointed out all those factors to say that they're reasons why CPU OEMs should be able to make all your dreams about price, quality, speed, open hardware come true?
It was about the market being difficult to enter. If you disagree, prove me: I hereby pledge to buy one CPU (needs to be a custom design) + mainboard designed and manufactured by supernova87a, and am willing to pay 800 US$, due 3m after delivery, conditional: It runs my Linux &Windows software like a, and performs at least equally or better than a, then-new system costing up to 400US$ (for cpu+mb, so today something like a Ryzen 1600). This agreement expires on 1.1.2025 0:00 UTC. Your call, do you agree? - Edit, also for balancing reasons: What do I get from you if you fail?
(Since I know you're not getting a x86 license that's an easy call for me - I know for sure you're unable to tap into that market)
You're right, but: In the unlikely case a random person on the internet succeeds (who knows what happens in the next 5 years, or who s/he is?), I am out of 800US$. For something that I think is a good idea. In case of 800m US$, well, I'm a little bit embarrassed to admit that I can't afford that right now ;-)
With a criminal penalty via the DMCA for bypassing it, because encryption is involved. That's why I'm so angry and want companies employing such encryption to be prevented from doing so or face prosecution.
So if I wanted to modify my car to unlock performance that's usually OK and certainly has been considered moral for decades. But if I wanted to unlock a core in my Ryzen CPU, or just hardware hack my GPU (Radeon Vega and above) to make it do neat tricks, I now technically risk a FELONY because of the PSP encryption and the DMCA - even though I want nothing to do with cracking copy protection. That is enough to have a chilling effect and prevent neat stuff from being released.
AMD have gone as far as signing the BIOS* on their recent GPUs, so tweaking it may be technically illegal (assuming you could crack the signature, though)!
This is unprecedented, nobody ever risked a potential felony for wanting to look inside their car to see how it works, or modifying their household appliances.
We need to get together (on Twitter and other social media) to fight this and let consumers know what is happening, because if people did, especially the more technically minded enthusiasts/gamers, that would put pressure on AMD and others to stop.
Specifically for gamers, let them know it's likely a FELONY to unlock a core in their Ryzen CPU or Radeon GPU due to PSP crypto. Just as with the ink cartridge recyclers who have been prosecuted for breaking cartridge chip security.
* = Radeon Vega and later GPUs have a Cortex-A5 PSP which runs autonomously, executing the Trustonic TEE from the SPI BIOS chip at boot, once the signature has been verified. Yes a whole DRM operating system running on the GPU - if you want to see for yourself, take a Radeon Vega or later BIOS and run binwalk -e to extract the compressed TEE.
The title as submitted to HN is super clickbaity. Overall this doesn't seem 'bad', aside from some questionable defaults that other commenters said about it being enabled by default.
This may well be a case of the vendor does this, they get a better price as removes all aspects of reselling the CPU's on and the whole grey market risk - https://en.wikipedia.org/wiki/Grey_market
Large vendor, such details may mean a few dollars saving on the CPU's and that will add up. For many it won't be an issue, more a gotcha for the second hand market upon those thinking they can buy and part it out. So down the line, this is going to make some second hand CPU's a real gotcha unless these chips have identifiable visible marking.
Is there any way to “fix” the processor afterwards? Maybe send it to AMD to be reset? If I’m buying a multi thousand dollar processor, I’d feel better if I could reuse it in other systems if needed.
That’s about the only way I see out of this, yeah. No fuses blown is obviously a specific state (works as expected everywhere). All-fuses blown needs to be a specific state too (say the trustroot is dead and it’s now “just a cpu”).
You couldn’t just fail to that state (it’d be inappropriate for its primary use-case), as long as there’s some way to get there.
It could be done with some kind of JTAG mod-chip, but this depends on what kind of JTAG security they've implemented.
If you want to know where to start, search GitHub for 'KaveriPI', if you unpack AMD BIOSDBG.EXE you can find a complete list of processor registers. This is all from 2015 but the PSP is documented in there.
There's also a Microsoft Access database which has all the JTAG registers, but I don't have the time to decode the meaning of the fields... It is likely that things have changed since then but it still might be enough for a start.
Should the JTAG interface be protected then some kind of laser(?) fault injection might be required to open it up. I guest some of the eFuse bits can be overwritten, maybe there's a combination which can remove the lock. An innovative recycling company could work on making a jig to automate this somehow...
Some PSP JTAG stuff here (publicly available material from GitHub in 2015, fair use applies):
41469,3529,164000,164999,"SMU_PSP_efuse_ovr_tried",,1,0,0,0,50,"0000",0,
41470,3529,164000,164999,"SMU_PSP_FRA_pass_ld_err",,1,1,1,0,50,"0001",0,
41471,3529,164000,164999,"SMU_PSP_FRA_pass_ld_cor",,1,2,2,0,50,"0002",0,
41472,3529,164000,164999,"SMU_PSP_efuse_pdmb_aes_dis",,1,3,3,0,50,"0003",0,
41473,3529,164000,164999,"SMU_PSP_efuse_pcpu_dis",,1,4,4,0,50,"0004",0,
41474,3529,164000,164999,"SMU_PSP_efuse_ccp_cyph_dis",,1,5,5,0,50,"0005",0,
41475,3529,164000,164999,"SMU_PSP_efuse_FRA_en",,1,6,6,0,50,"0006",0,
41477,3529,164000,164999,"SMU_PSP_efuse_proto",,1,7,7,0,50,"0007",0,
41478,3529,164000,164999,"SMU_PSP_efuse_secure",,1,8,8,0,50,"0008",0,
41552,2352,164000,164999,"SMU_PSP_hard_resetb",,1,31,31,0,50,"101F",0,
41553,2352,164000,164999,"SMU_PSP_early_resetb",,1,30,30,0,50,"101E",0,
41554,2352,164000,164999,"SMU_PSP_slv_mbus2_reset",,1,29,29,0,50,"101D",0,
41555,2352,164000,164999,"PSP_SCAN_MODE_STICKY",,1,28,28,0,50,"101C",0,
41568,2352,164000,164999,"PSP_AEB_307_PCPU_RST_DLY_TDR_en_pclk",,1,15,15,0,50,"100F",0,
41569,2352,164000,164999,"PSP_AEB_304_PCPU_FORCE_rst_en_pclk",,1,14,14,0,50,"100E",0,
41579,2352,164000,164999,"PSP_Resetn",,1,8,8,0,50,"1008",0,
43605,555,164000,164999,"PSP_ENABLE_SPARE",,0,1,1,0,50,"0001",0,
43642,555,164000,164999,"PSP_SPARE",,0,7,14,0,50,"0007",0,
While I don't have the time to look at this myself, someone should really have a go at trying to crack this, here are some EPYC server schematics with the JTAG signals brought out to test points:
AMD is unlikely to sue anyone trying to reverse engineer the JTAG interface, especially if it's for an open source project to unbrick CPUs! If they do the EFF is very likely to step in and defend you.
Also on old AMD hardware (SMC based GPU/CPU?) there is a very critical time period JUST after the device comes out of reset and before the SMC starts to lock everything down. Then you can access 'secret' SMC registers through JTAG and read out the protected SMC ROM for example (just keep resetting the device over and over, while stepping the SMC address one by one). The SMC's CPU is a Lattice Mico32 (LM32). In the SMC ROM is a symmetric crypto key which used for authentication (SHA1).
The SMC ROM contains code to initialize the hardware before the PCIe links are brought up. One of the first things the SMC does after boot is read out the eFuse contents and program various 'write once' lockdown registers which are used to disable features within the chip. Once these registers have been written to they cannot be modified until a hard reset occurs. So you write to these before the SMU gets a chance to. Or you can halt the SMC itself, then write whatever registers you want and reboot it as nothing ever happened. That way you can override many of the eFuse related settings.
The above techniques might also work on PSP based CPUs/GPUs - so you need to access the JTAG interface ASAP after bringing the chip out of reset. I'm unsure if the SMC is still present on the PSP-based CPUs and GPUs, as I don't have any spare to test.
Honestly I see this as a net positive. It increases the security of the server, which is good for everyone. The secondary market will adjust accordingly, probably by selling the processor/motherboard/barebones server together. The only issue I can see is that there is no way to distinguish a locked processor from an unlocked one.
> It increases the security of the server, which is good for everyone
That is exactly the point: it isn't good for everyone. In particular, it is suspicious that a move in the name of security just so happens to negatively affect the secondary market. A market that by definition doesn't net AMD any money.
If AMD had released this exact same feature and said "we are doing this because the second-hand market is bad for our sales", regulators would immediately jump at them for anti-competitive behavior. And the fact that there is no option to disable this check at all makes it even more suspicious.
It is possible that the benefits outweigh the downsides. But I wouldn't give them a pass that easily.
Yes, I think that would be a valid way to bypass the protection.
With physical access you can bypass just about any protection given enough money and time. In a data centre context, the damage you can do is rapidly minimised by rapidly increasing the amount of capital and time required to access more of the DC.
The more important change is that without this feature, malware could theoretically install itself into the firmware without requiring physical access. Now it should be just about impossible to break the chain of trust without a person physically tampering with the machine.
Note: I should mention that I think this is such a massive double edged sword (maybe double edged shield is a better term). This lets you build a threat model that accounts for everything up to physical access. This however also has such a massive opportunity to be an incredibly anti-consumer feature that I fear to see how it will be used. I wish they would have required a physical switch to enable/disable the feature. I do however understand how adding such a feature could complicate its implementation quite a bit.
I'm not as sketched out about this as if it were single socket workstation ryzen/threadripper CPUs. In the market from $1000 to $6000 workstation desktops where enthusiasts and people with specific requirements (or just 10, 15, 20 years of experience building x86-64 PCs themselves) would want to build their own desktop from individual components ordered off Newegg.
I doubt more than a single digit percentage of 'serious' dual socket (64-128+ core) rackmount server customers are going to be buying their own barebones motherboards and CPUs and assembling it themselves. They're going to buy it from a Dell, HP or a Supermicro integrator or similar. If you're buying a $12,000+ server with 128 cores and 512GB to 4TB+ of RAM and some fast NVME storage it's highly unlikely you're putting it together yourself.
Any massive hosting/cloud scale operations that want to DIY their own EPYC systems from pieces will be doing it through a Taiwanese integrator, such as those that supply the ecosystem components for open compute platform server motherboards. And as such they'll also not encounter any technical issues or procurement issues with this. At the point where you have two $3000 CPUs on a motherboard that costs $1200, the full firmware/motherboard/CPU integration and qualification process is very different than putting a $399 ryzen into a $300 board.
Not yet. We will in 5 years time when their resale value meets our budgets.
I work in a rather budget-constrained lab environment. “Beg, borrow, steal” is the order of the day. Just today I was pricing out pre-loved Gen8 HPs. In 5 years time I could be exactly the hypothetical the article outlines.
This isn’t today’s problem - it’s a problem we’re creating today. We’ll hit it when your examples start retiring them and my example are eager to recycle them.
Yes - and no, I know lots of people including myself who have things like older dual socket Dell R710 as home test hypervisor servers. Also a very tiny percentage of people will bother to ever upgrade the CPUs on them.
For home lab stuff... When people buy a $200 used Dell R610 off ebay with two 8-core CPUs they most likely expect to use it in the exact same CPU configuration. Maybe add RAM. And probably use their own choice of SATA 6Gbps SSD in the drive trays instead of whatever old, possibly unreliable used spinning drives might come with it.
I have a 4U, quad socket Dell R910 with 32 total cores and 256GB of RAM that I got for $350. I'm absolutely not going to go messing around with replacing the CPUs on it with something I've purchased from ebay. When it's too old or slow, or I'm tired of having a 500W electrical load in my garage, I'll replace it with another thing that's come off a 3-4 year lease cycle.
My go-to vendor’s business model is to do that for me. So I say, I want a DL360. I pick processors, ram, disk controllers from their stock. I can even tell them how many caddies I want (looking at you, Dell). And they ship me a build-to-order server from second-hand parts.
So in the future I’ll likely have a smaller bin of CPUs to choose from. If firmware keys get more specific than per-vendor, it could be potentially a very small bin. And small bins typically mean higher costs. The cheapest cpu is typically the biggest bin, not the highest specced.
I haven't yet purchased used server gear, but I do a lot of window shopping. Most of the servers come with CPUs, but not all of them, and there's always a lot of loose CPUs for sale. Very occasionally, I've seen new-old-stock server motherboards for sale for not too much.
I have never purchased a used server and aruck with the included CPU’s, they’re either power hungry beasts or bottom-rung SKU’s. All of my 12th gen PowerEdge servers at home run E5-2450L’s (they’re all -EN platforms), for example. The one exception is the R210 II I use as a firewall/router.
By percentage the number of 1U/2U servers sold with ultra power efficient CPUs is fairly low. When people buy those new they will absolutely be going for CPUs that are 85W to 130W TDP per socket, times two sockets.
As a person that's formerly worked for a server manufacturer for a number of years I would say that the mid to upper performance range of the CPU market is 80%+ of the servers by volume. The other 10% is either the very low power models, and the top 10% of the units sold by volume are the very most expensive CPUs available at the time.
If you buy a used 1U Dell R610 with two six-core CPUs and 64GB of RAM, nobody should be surprised that a 120VAC watt meter at the wall shows it idling at 150W power consumption, with cpu load at 0.00... [surprisedpikachu.gif]
I mean, they don’t have to be the ultra-efficient ones - but for my home lab use I want < 100W idle usage and even my R520 can handle that with the 2450L’s (Ivy Bridge-EN could do this without the L suffixed SKU’s, but HCC chips in that family were more expensive when I was buying).
> I work in a rather budget-constrained lab environment. “Beg, borrow, steal” is the order of the day. Just today I was pricing out pre-loved Gen8 HPs. In 5 years time I could be exactly the hypothetical the article outlines.
Likewise for me. I AM building a $20,000 HPC because simply put, no one will sell us one for anything close to what we can actually afford and when it affects the speed and capability of my research and publications personally, it feels like a waste to leave extra performance on the table.
If I may ask, using what motherboard? The problem of EPYCs being locked to a certain vendor platform should not be a problem for you if you're buying a factory new Supermicro or Tyan or competing board. And a new set of individually purchased EPYC CPUs.
As a University student, I had dual Athlon XPs on a Tyan board. It was a lot of money for me back then, and the power supply melted to the board (not the power supply's fault either. I soldered on a new ATX connector and the 2nd power supply also melted to the board). If I couldn't use those processors in any other machines except a Tyan, I would be insanely pissed off.
The "this is for security" argument would make sense if they only locked CPUs that were sold by the vendor together with the motherboard, or if they had an action that an administrator could affirmatively take to lock the CPU.
But automatically, permanently "poisoning" any CPU that's inserted into the socket after a single boot? That sounds like it's being done for economic reasons.
They want to turn the used CPU market into a sketchball market for lemons so that everyone is so scared that they only buy board+CPU combos directly from the vendor rather than trying to save a few pennies here and there.
I don't know, when you think about what makes easier (cheaper) for the vendor, this way they just have to assemble the CPUs into the motherboards and ship the systems like they always have.
I can't see that the market for enterprise system is heavily affected by grey market CPUs. Their customers are by and large buying these systems built & configured, and racking them up as they come.
It'd be nice if there was a jumper you could set on the motherboard to stop it claiming a CPU though (maybe there even is?).
My understanding was that you can put this in any other motherboard with the same signing key. Presuming the intent her is that every single machine would have to have a different signing key. If this was the case, then yes, security seems to be the reason.
However, and I may have misunderstood this so please do correct me if I have, based on the article, it seems for certain vendors, they share the same signing key with multiple machines (presuming whole lines), in which case this certainly seems to be about vendor lock-in from the vendor side.
If I put a cpu in a server (Dell, HP, whatever), and that CPU then doesn't function in other equipment, than that cpu is broken. That's not an exaggeration in any way.
So, the server maker then owes me a new cpu (of the same model obviously) that does work.
It'll be interesting to see the legal fallout from this, as purposely breaking customer owned gear is not going to end well.
While shitty, if this required pre-programmed OEM CPU’s it would be one thing - but knowing I could put a several thousand dollar boxed CPU into a branded motherboard and have it perpetually locked to that OEM is horrible.
Quite frankly this should be an optional security feature I can flip off with a physical switch on the board - go show an alert on the BMC for all I care, but as is this is total bullshit.
While reaching out directly to the company is definitely a strong way to express disagreement, I almost guarantee that someone from AMD PR will be reading through comments on tech community posts like these.
Expressing discontent in an open forum can catalyse a much larger reaction that PR depts will pay much more attention to compared to a few angry emails or twitter DMs.
This entirely depends on individual's perspective.
As Chris mentioned, this is exactly what Big Corp™ wants. They'll be the ones buying it too, and would likely pay extra for such a feature. They're the target market for these vendors.
Thus, sure, for those looking to buy second hand, this is indeed advertising irreparable damage. But for Big Corp™, this is advertising security (in my opinion quite rightly so), and ensuring their data isn't stolen.
It becomes a problem when there's a monopoly or a duopoly of suppliers and there are no suitable alternatives on the market with similar performance characteristics. I believe then the FTC can get involved with antitrust matters if they are abusing their dominant position to prevent reuse/recycling.
Australian Consumer Law would make Dell liable for damages if anyone bought a computer from them that damaged a CPU by design. I don't even think that having a warning attached would be a sufficient shield, because it's impossible to 100% guarantee that an end user fully comprehends the consequences of a computer that is designed to permanently alter how their CPU functions.
> It'll be interesting to see the legal fallout from this, as purposely breaking customer owned gear is not going to end well.
IANAL; I wonder if this would be grounds for a class-action lawsuit in the future. Something like suing the motherboard manufacturers to replace every CPU their boards have broken by this method.
I thought this type of system would provide a way to revert to factory defaults with a side effect of erasing all keys. So the processor would no longer be secure, but would at least still boot. Maybe this clearing can be done through the BIOS/UEFI on the original Dell system.
How many exploits/breaches in the wild due to open s3 bucket, default admin passwd to database, poorly written webshit code, plaintext password, etc. ? And how many prevented by secure boot, boot guard, memory encryption, ME, PSP etc. ? Other than obvious money reasons for Dell, people seem to be vastly overestimating their threat models. And even for the secure chain of trust, there are ways to do so where the owner has the key, not the vendor. See heads for example.
Or, those scenarios just don't make the news as frequent as script kiddie stuff. We only learned about what NSA has been up to because Snowden happened.
If I want to protect against the NSA I'm worried about them using Intel ME, AMD PSP and other black boxes to hack me. I don't worry that much about them sneaking into my data center or house and physically changing my hardware.
The security you lose from having a black box in your CPU is much greater than the security you win by virtue of being (theoretically) protected against unsigned bootloaders and rogue hardware.
No, everyone with half a brain knew, but was called a conspiracy theorist for years. Then Snowden was a controlled release with virtually the same information, and it was approved by the mainstream media. Plus his stamp of approval was on Signal "for whistleblowers" :P
Although a PSP flaw is very unlikely to harm an individual user, it puts the US and it's intellectual property at risk from foreign actors such as Russia or China. And many engineering firms do not have the resources of the NSA to protect against such threats.
Additionally, a PSP or Intel ME related hack involving a SCADA system would not be discovered until it's too late, with potentially extremely severe consequences. AMD is advertising the processor as being a security device that is intended to enhance system security. If such a SCADA hack involving the PSP was to result in loss of life for example, what would AMD's liability be in such circumstances, where the 'security device' itself has enabled the system to be hacked in the first place? Taking into account that the 'security device' cannot be disabled by the SCADA operator, so they have no choice to use it.
That is why I believe the PSP and ME should be removed completely. Should that not be possible it should be replaced with a processor that is transparent to its internal operation.
This is bullshit. Unless it clearly says at boot 'continuing will permanently prevent your CPU from being used in a non Dell computer y/n?' they are asking for a lawsuit for damaging hardware
Do consumer laws apply to businesses in Australia? Because afaik, in the EU regretfully a lot of laws that protect consumers against abuse from vendors, do not apply to B2B/enterprise transactions.
On the other hand, there have been people who have warned about the dangers of CPU vendors putting Management Engines in their products, which are outside of the control of end users (by design). One of those concerns was the ability to rig sales or even kill off second hand markets markets all together. Apparently, this have already become a reality now.
I'm not surprised it's sold as security feature, just as terrorism and child pornography have been magic words in other fields. But at the end of the day, vendors stand to substantially increase their control on sales and with it their profits, with features that may only be significant in edge cases. That smells a lot like an antitrust issue to me. That all vendors are likely try to move in this same direction, as an opportunity to make more profit, doesn't make it any less devious. All the more reason for antitrust investigators to start looking into this.
> Do consumer laws apply to businesses in Australia? Because afaik, in the EU regretfully a lot of laws that protect consumers against abuse from vendors, do not apply to B2B/enterprise transactions.
Yes. Consumer protections apply to everyone. Within Australia, those protections are considered the "bare minimum" that must be implemented by every business, across the board.
Certain industries have other protections they must implement atop of those.
If that's true, and I have to admit that's a big surprise for me, then I'm glad to hear that. At least for Australia.
I'm not even sure if the following is uniform across the EU, but I have always assumed (maybe even been told) that it is. Where I come from (The Netherlands), (afaik) when you do business with another business then consumer protection laws don't apply.
The rational appears to be that as a business you don't need the same kind of protection as a consumer. It's considered the risk of doing business, and companies suing each other in court (e.g. for fraud) is considered to be less unbalanced than it would be for private individual (consumer) against a company, in terms of (financial/legal) means.
In reality there probably are different (less savory) historical reasons behind it too, maybe even the preservation of the "natural power distribution" (euphemism for the already wealthy to stay that way) between smaller and larger businesses. That's at least how I have heard it being justified politically. Meanwhile, good luck suing a large company if you're a smaller business yourself. Either way, as I already implied, I think that's more or less by design.
Great if Australia is more egalitarian on that subject. If not for all of nature tring to kill me at every second there, I'd seriously consider immigrating over this xD
I can think of two scenarios where this security feature is helpful.
First, somebody breaks into a server room, replaces the motherboard with a compromised one, and notices mid replacement that they forgot a processor. (Since the processor locks during first boot, it is of no use if the supply chain is compromised before the first boot. On the other hand, I would imagine somebody willing to break into a data center to replace a motherboard would also be willing to do all kinds of other shenanigans, like bringing another processor.)
The second scenario is, somebody thinks about buying a used instead of an new processor.
Well, the security key of VM is stored in the CPU, so you can't replace CPU unless you can enter the console, copy the data out and re-encrypt it with key from another CPU.
While if you can do this, you don't need to replace mother board/CPU anyway because you already pwned them and copy/modify the data whatever you want.
The article talks about virtual machines as a subset of memory encryption. It also specifically says "ephemeral keys". Not ones that would be preserved across a shutdown.
What is encrypted on a powered-off server that the CPU knows the key to?
I mean keys stored in cpu ftpm.
So next time it boot, it can't get the disk decrypted with the key in the cpu.
And the admin will notice something very incorrectly happened.
This sounds reasonable. I mean to bypass this lock our criminal would have to ... replace the CPU and continue attack like nothing happened. Totally infeasible, inconceivable even! proving this was introduced for safety and not Vendor_lock-in!!!1
Sorry to be blunt, but am I correct that this is a measure against tampering with servers by Chinese intelligence during the customs process?
In that case, are the CPUs themselves signed or could they be replaced after modifying the motherboard?
Because otherwise it's really hard why the website would claim that every end user would be enthused about these lock-ins. Sort of weird statement.
I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.
265 comments
[ 6.7 ms ] story [ 394 ms ] threadIt also won't necessarily work in other Dell motherboards, just ones using the same key as the first.
It's strange Dell would blow the fuses by default, though.
This will greatly complicate the future second-hand market, though. Buying used Epyc CPUs off of ebay in 5 years will become very sketchy for example.
Used SGI to not pick a real vendor.
As in for your example there isn't anything stopping you from buying a CPU from anyone, including US retailers, and using it in an SGI EU motherboard. The CPU itself isn't locked when new, this signing key locking isn't baked into the CPU at the factory. It happens when you plop it into the socket & fire it up for the first time.
I can't buy a used cpu from an SGI US customer and put it in an SGI EU motherboard. I can buy a new CPU from anyone though, but then I can only sell it in-region.
Correct, but that's less a region thing and more this just poisons all used CPUs.
As in you don't even know if an SGI US CPU will work in a different SGI US motherboard. There's no particular reason to assume all SGI US motherboard models will have the same signing key. Within the same model that'd almost certainly be the case, but if it's a different model, especially different chipset, I don't know why they would necessarily strive to keep the key the same across different firmware branches.
> I can buy a new CPU from anyone though, but then I can only sell it in-region.
Er, why? Nothing about this stops you from re-selling CPUs however you want. Or are you still talking about the used market here?
It provides a mechanism to prove the entire boot process hasn't been tampered with, but I wish AMD provided a way to run these fused processors in a generic way without the security chain, with it just reporting that there isn't a secure root of trust. However I assume they are afraid of that allowing malicious code to fool deeper parts of the system without the system administrator knowing.
So good for security, but bad for e-waste and second hand sales.
It’s an interesting problem. The solution is valid, but it’s unfortunately permanent.
Also, we sometimes lose the CPU rather than the board. As the CPUs become more complex, their probability to fail has risen.
I guess that's the key point here.
What I am most worried about is vendor's key becoming compromised (whether cracked or stolen), which means that a revocation mechanism is missing.
Even with revocation implemented, such equipment would be rendered useless (I imagine vendor would have to cover for replacements).
(This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)
Fun trivia. The boot loader signing in the raspberry pi works the same way.
Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.
Note - there is even a fuse that when blown, prevents other fuses from being blown!
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-323...
I believe Xbox 360 one was rewritable while Switch one is not. They also require higher voltages than rest of CPU to write. So modders used to modify PCB to block writes or tried to write old values. For Switch they had unrelated nonupdatable boot exploits to bypass signature checks for early batches.
And the simplest answer is that code could check if the fuses are reading out too early a version and abort. Which you could try to patch around but it won't be easy.
this made me think of the pencil trick from the earliest days of socketed athlons. not exactly the same I know.
I had the same initial reaction though. It seems like something that makes more sense as a jumper or something that can be reset by jumper so physical access becomes the requirement.
The only reason I can think of to do it as described is to kill the secondary market or, even worse, to maintain a lifetime licensing requirement on the system. If the signing keys can expire like signing certificates I expect step 2 will be custom signed firmware via a cloud portal where no license means no signing. I hope I'm wrong, but that's likely the endgame here.
TLDR; If the signature on the BIOS can expire, it's more nefarious than it sounds IMO.
The header pins can be varnished (or other techniques) so they do not conduct, but they still look normal. To set a pin, 36GA wire between the plastic of the header and the PCB would do the trick. If the adversary had a particularly high budget, they could fabricate and install a header that would even pass inspection by a multi-meter's continuity check by making the outer part of the pins be electrically isolated from the inner, except where it contacts the PCB, where the attackers choice of conductivity is made.
I don't think anyone has come up with a good way to downgrade the CPU from secure operation to insecure without also creating a way to bypass it for an attacker. The only way I can think of is if there was a revocation of secure mode that put the CPU serial number on a public list, then after a week, the CPU blew a fuse allowing it to boot in insecure mode. It will allow enterprises to be assured that the computers they are sending all over the globe are untampered, but still allow people who don't care to get them second hand and not be stuck with the rest of the computer. The hard part is making sure the CPU can only blow that fuse after it gets an ack that its been a week. Ideally, there would be some way for the CPU to attest which mode its running in so secondary audits of the CPU's state can be performed.
If they have physical access and are replacing the BIOS, they could just replace the CPU at the same time with a fresh unlocked one that will lock itself to the replacement's signing key on first boot.
If you care about this specific attack scenario then make sure you check the keys with a management tool or something. It's not necessary to make the chip unusable for almost every aftermarket user just to make it a little bit clearer that a compromise has happened in that rare case.
I'm just trying to speculate what might be driving demand for this type of feature, since TPMs already exist.
I concur, but it's true for even consumer devices like smartphones. Once the software updates stop, if security is the key then the devices are e-waste. Many times, I wish there was an International law which forces manufacturers to unlock their device when they stop pushing software updates to their device, so that alternate firmware can be installed. Of course this is just a wishful thinking, even those who abandoned their smartphone segment entirely(MS) didn't do this, So why would those who run profitable business out of planned obsolescence do it?
It doesn't go as far as to force unlocking, but requiring transparent disclosure of a committment to security update longevity (like Chromebooks and pixel phones have) is probably the first step along the road to that.
Basically, "doesn't go as far as" sounds like a massive understatement.
I see, so it's basically AMD's implementation of Intel Boot Guard, but on servers instead of laptops. On boot, the CPU verifies the BIOS's signature from its OTP memory and refuses to boot if verification fails.
Theoretically, if you move CPUs between different laptops, you'll find the CPUs are locked to its platform as well, but we don't feel it since they are not replaceable, the only visible effect is that the firmware has been locked and you cannot run coreboot.
And now the same thing is coming to servers and it has a bigger visible effect...
It could be implemented in a way that preserves the ability to reuse CPUs, but it wont be.
This is entirely debatable. This is essentially bootguard for socketed CPUs similar to how most laptops behave. For one, it makes fixing the crap that Dell and their contractors write impossible. You cannot replace the bios with coreboot.
For all these features that require blessings, I really liked apple's use of the term notarised. Everyone should call these notarisation features rather than security ones. It's as boring and useless as going to a notary, if you have ever done that.
They've become a bigger concern with UEFI since it has a massive attack surface compared to legacy BIOS.
For a processor sitting in AWS / Azure, they want guarantees, and they're the ones EPYCs are designed for.
The responsibility has to rest with the processor, since it's the only thing executing code prior to UEFI. What it's doing is validating that UEFI was cryptographically signed with the correct key prior to running any UEFI code. When it's first used, it is saving the key for the vendors UEFI implementation and won't allow it to proceed if the root signature ever changes (think something similar to root certs for HTTPS).
It's only relevant to Secure Encrypted Virtualization insofar as they are both implemented inside the PSP which is a separate ARM core that runs at a higher privilege level than the x86 cores (and is the core that actually initializes the x86 cores).
This is how all phones have worked for many years, but apparently it's now becoming a thing in servers too.
The motherboard just loads BIOS/UEFI into a predefined memory address and then starts the CPU
This is a pretty good explanation https://manybutfinite.com/post/how-computers-boot-up/
> In a multi-processor or multi-core system one CPU is dynamically chosen to be the bootstrap processor (BSP) that runs all of the BIOS and kernel initialization code
These days, the "bootstrap processor" is a separate core that your OS can't see. On Intel it's the IME (running Minix) and on AMD it's the PSP (ARM TrustZone)
If one segment needs to worry about UEFI rootkits, it's cloud vendors. Very dedicated (nation-state sponsored) attackers could burn/use a zero-day hypervisor escape to installs a UEFI rootkit that tampers with the processor's integrated HSM (as said in the article, tampering with it has already happened and the exploits have been patched by AMD). As I understand it, If a vendor uses full memory encryption, the above exploit could lead to decrypting and exfiltrating other customers' data.
*Jokes aside, I think Intel created UEFI (for Itanium?), not Microsoft?
But yes, its really shitty how the downsides end up with the loss of user control and ewaste. Especially when it is possible to design something that is secure and that the user controls.
It surely makes sense for phones as it makes less profitable to steal them (as you could only sell parts of the phone and even that can be blocked). Maybe even for laptops but not for desktops and servers.
You pointed out all those factors to say that they're reasons why CPU OEMs should be able to make all your dreams about price, quality, speed, open hardware come true?
Makes perfect sense.
(Since I know you're not getting a x86 license that's an easy call for me - I know for sure you're unable to tap into that market)
So if I wanted to modify my car to unlock performance that's usually OK and certainly has been considered moral for decades. But if I wanted to unlock a core in my Ryzen CPU, or just hardware hack my GPU (Radeon Vega and above) to make it do neat tricks, I now technically risk a FELONY because of the PSP encryption and the DMCA - even though I want nothing to do with cracking copy protection. That is enough to have a chilling effect and prevent neat stuff from being released.
AMD have gone as far as signing the BIOS* on their recent GPUs, so tweaking it may be technically illegal (assuming you could crack the signature, though)!
This is unprecedented, nobody ever risked a potential felony for wanting to look inside their car to see how it works, or modifying their household appliances.
We need to get together (on Twitter and other social media) to fight this and let consumers know what is happening, because if people did, especially the more technically minded enthusiasts/gamers, that would put pressure on AMD and others to stop.
Specifically for gamers, let them know it's likely a FELONY to unlock a core in their Ryzen CPU or Radeon GPU due to PSP crypto. Just as with the ink cartridge recyclers who have been prosecuted for breaking cartridge chip security.
* = Radeon Vega and later GPUs have a Cortex-A5 PSP which runs autonomously, executing the Trustonic TEE from the SPI BIOS chip at boot, once the signature has been verified. Yes a whole DRM operating system running on the GPU - if you want to see for yourself, take a Radeon Vega or later BIOS and run binwalk -e to extract the compressed TEE.
> AMD PSB Vendor Locks EPYC CPUs for Enhanced Security at a Cost
Large vendor, such details may mean a few dollars saving on the CPU's and that will add up. For many it won't be an issue, more a gotcha for the second hand market upon those thinking they can buy and part it out. So down the line, this is going to make some second hand CPU's a real gotcha unless these chips have identifiable visible marking.
You couldn’t just fail to that state (it’d be inappropriate for its primary use-case), as long as there’s some way to get there.
If you want to know where to start, search GitHub for 'KaveriPI', if you unpack AMD BIOSDBG.EXE you can find a complete list of processor registers. This is all from 2015 but the PSP is documented in there.
There's also a Microsoft Access database which has all the JTAG registers, but I don't have the time to decode the meaning of the fields... It is likely that things have changed since then but it still might be enough for a start.
Should the JTAG interface be protected then some kind of laser(?) fault injection might be required to open it up. I guest some of the eFuse bits can be overwritten, maybe there's a combination which can remove the lock. An innovative recycling company could work on making a jig to automate this somehow...
Some PSP JTAG stuff here (publicly available material from GitHub in 2015, fair use applies): 41469,3529,164000,164999,"SMU_PSP_efuse_ovr_tried",,1,0,0,0,50,"0000",0, 41470,3529,164000,164999,"SMU_PSP_FRA_pass_ld_err",,1,1,1,0,50,"0001",0, 41471,3529,164000,164999,"SMU_PSP_FRA_pass_ld_cor",,1,2,2,0,50,"0002",0, 41472,3529,164000,164999,"SMU_PSP_efuse_pdmb_aes_dis",,1,3,3,0,50,"0003",0, 41473,3529,164000,164999,"SMU_PSP_efuse_pcpu_dis",,1,4,4,0,50,"0004",0, 41474,3529,164000,164999,"SMU_PSP_efuse_ccp_cyph_dis",,1,5,5,0,50,"0005",0, 41475,3529,164000,164999,"SMU_PSP_efuse_FRA_en",,1,6,6,0,50,"0006",0, 41477,3529,164000,164999,"SMU_PSP_efuse_proto",,1,7,7,0,50,"0007",0, 41478,3529,164000,164999,"SMU_PSP_efuse_secure",,1,8,8,0,50,"0008",0, 41552,2352,164000,164999,"SMU_PSP_hard_resetb",,1,31,31,0,50,"101F",0, 41553,2352,164000,164999,"SMU_PSP_early_resetb",,1,30,30,0,50,"101E",0, 41554,2352,164000,164999,"SMU_PSP_slv_mbus2_reset",,1,29,29,0,50,"101D",0, 41555,2352,164000,164999,"PSP_SCAN_MODE_STICKY",,1,28,28,0,50,"101C",0, 41568,2352,164000,164999,"PSP_AEB_307_PCPU_RST_DLY_TDR_en_pclk",,1,15,15,0,50,"100F",0, 41569,2352,164000,164999,"PSP_AEB_304_PCPU_FORCE_rst_en_pclk",,1,14,14,0,50,"100E",0, 41579,2352,164000,164999,"PSP_Resetn",,1,8,8,0,50,"1008",0, 43605,555,164000,164999,"PSP_ENABLE_SPARE",,0,1,1,0,50,"0001",0, 43642,555,164000,164999,"PSP_SPARE",,0,7,14,0,50,"0007",0,
https://pbs.twimg.com/media/D3jU2ZuU8AE_JgS?format=jpg&name=...
AMD is unlikely to sue anyone trying to reverse engineer the JTAG interface, especially if it's for an open source project to unbrick CPUs! If they do the EFF is very likely to step in and defend you.
The SMC ROM contains code to initialize the hardware before the PCIe links are brought up. One of the first things the SMC does after boot is read out the eFuse contents and program various 'write once' lockdown registers which are used to disable features within the chip. Once these registers have been written to they cannot be modified until a hard reset occurs. So you write to these before the SMU gets a chance to. Or you can halt the SMC itself, then write whatever registers you want and reboot it as nothing ever happened. That way you can override many of the eFuse related settings.
The above techniques might also work on PSP based CPUs/GPUs - so you need to access the JTAG interface ASAP after bringing the chip out of reset. I'm unsure if the SMC is still present on the PSP-based CPUs and GPUs, as I don't have any spare to test.
You do understand that this can be fairly annoying, yes?
That is exactly the point: it isn't good for everyone. In particular, it is suspicious that a move in the name of security just so happens to negatively affect the secondary market. A market that by definition doesn't net AMD any money.
If AMD had released this exact same feature and said "we are doing this because the second-hand market is bad for our sales", regulators would immediately jump at them for anti-competitive behavior. And the fact that there is no option to disable this check at all makes it even more suspicious.
It is possible that the benefits outweigh the downsides. But I wouldn't give them a pass that easily.
With physical access you can bypass just about any protection given enough money and time. In a data centre context, the damage you can do is rapidly minimised by rapidly increasing the amount of capital and time required to access more of the DC.
The more important change is that without this feature, malware could theoretically install itself into the firmware without requiring physical access. Now it should be just about impossible to break the chain of trust without a person physically tampering with the machine.
Note: I should mention that I think this is such a massive double edged sword (maybe double edged shield is a better term). This lets you build a threat model that accounts for everything up to physical access. This however also has such a massive opportunity to be an incredibly anti-consumer feature that I fear to see how it will be used. I wish they would have required a physical switch to enable/disable the feature. I do however understand how adding such a feature could complicate its implementation quite a bit.
I doubt more than a single digit percentage of 'serious' dual socket (64-128+ core) rackmount server customers are going to be buying their own barebones motherboards and CPUs and assembling it themselves. They're going to buy it from a Dell, HP or a Supermicro integrator or similar. If you're buying a $12,000+ server with 128 cores and 512GB to 4TB+ of RAM and some fast NVME storage it's highly unlikely you're putting it together yourself.
Any massive hosting/cloud scale operations that want to DIY their own EPYC systems from pieces will be doing it through a Taiwanese integrator, such as those that supply the ecosystem components for open compute platform server motherboards. And as such they'll also not encounter any technical issues or procurement issues with this. At the point where you have two $3000 CPUs on a motherboard that costs $1200, the full firmware/motherboard/CPU integration and qualification process is very different than putting a $399 ryzen into a $300 board.
I work in a rather budget-constrained lab environment. “Beg, borrow, steal” is the order of the day. Just today I was pricing out pre-loved Gen8 HPs. In 5 years time I could be exactly the hypothetical the article outlines.
This isn’t today’s problem - it’s a problem we’re creating today. We’ll hit it when your examples start retiring them and my example are eager to recycle them.
For home lab stuff... When people buy a $200 used Dell R610 off ebay with two 8-core CPUs they most likely expect to use it in the exact same CPU configuration. Maybe add RAM. And probably use their own choice of SATA 6Gbps SSD in the drive trays instead of whatever old, possibly unreliable used spinning drives might come with it.
I have a 4U, quad socket Dell R910 with 32 total cores and 256GB of RAM that I got for $350. I'm absolutely not going to go messing around with replacing the CPUs on it with something I've purchased from ebay. When it's too old or slow, or I'm tired of having a 500W electrical load in my garage, I'll replace it with another thing that's come off a 3-4 year lease cycle.
So in the future I’ll likely have a smaller bin of CPUs to choose from. If firmware keys get more specific than per-vendor, it could be potentially a very small bin. And small bins typically mean higher costs. The cheapest cpu is typically the biggest bin, not the highest specced.
As a person that's formerly worked for a server manufacturer for a number of years I would say that the mid to upper performance range of the CPU market is 80%+ of the servers by volume. The other 10% is either the very low power models, and the top 10% of the units sold by volume are the very most expensive CPUs available at the time.
If you buy a used 1U Dell R610 with two six-core CPUs and 64GB of RAM, nobody should be surprised that a 120VAC watt meter at the wall shows it idling at 150W power consumption, with cpu load at 0.00... [surprisedpikachu.gif]
Likewise for me. I AM building a $20,000 HPC because simply put, no one will sell us one for anything close to what we can actually afford and when it affects the speed and capability of my research and publications personally, it feels like a waste to leave extra performance on the table.
But automatically, permanently "poisoning" any CPU that's inserted into the socket after a single boot? That sounds like it's being done for economic reasons.
They want to turn the used CPU market into a sketchball market for lemons so that everyone is so scared that they only buy board+CPU combos directly from the vendor rather than trying to save a few pennies here and there.
I can't see that the market for enterprise system is heavily affected by grey market CPUs. Their customers are by and large buying these systems built & configured, and racking them up as they come.
It'd be nice if there was a jumper you could set on the motherboard to stop it claiming a CPU though (maybe there even is?).
However, and I may have misunderstood this so please do correct me if I have, based on the article, it seems for certain vendors, they share the same signing key with multiple machines (presuming whole lines), in which case this certainly seems to be about vendor lock-in from the vendor side.
So, the server maker then owes me a new cpu (of the same model obviously) that does work.
It'll be interesting to see the legal fallout from this, as purposely breaking customer owned gear is not going to end well.
Quite frankly this should be an optional security feature I can flip off with a physical switch on the board - go show an alert on the BMC for all I care, but as is this is total bullshit.
Expressing discontent in an open forum can catalyse a much larger reaction that PR depts will pay much more attention to compared to a few angry emails or twitter DMs.
If you don't want a platform-secured CPU, don't buy one.
As Chris mentioned, this is exactly what Big Corp™ wants. They'll be the ones buying it too, and would likely pay extra for such a feature. They're the target market for these vendors.
Thus, sure, for those looking to buy second hand, this is indeed advertising irreparable damage. But for Big Corp™, this is advertising security (in my opinion quite rightly so), and ensuring their data isn't stolen.
Admittedly it feels like AMD could have created something that allows the chip to be reset providing you have the original signing keys.
...the problem is what happens when you buy an unlocked CPU.
IANAL; I wonder if this would be grounds for a class-action lawsuit in the future. Something like suing the motherboard manufacturers to replace every CPU their boards have broken by this method.
The security you lose from having a black box in your CPU is much greater than the security you win by virtue of being (theoretically) protected against unsigned bootloaders and rogue hardware.
Additionally, a PSP or Intel ME related hack involving a SCADA system would not be discovered until it's too late, with potentially extremely severe consequences. AMD is advertising the processor as being a security device that is intended to enhance system security. If such a SCADA hack involving the PSP was to result in loss of life for example, what would AMD's liability be in such circumstances, where the 'security device' itself has enabled the system to be hacked in the first place? Taking into account that the 'security device' cannot be disabled by the SCADA operator, so they have no choice to use it.
That is why I believe the PSP and ME should be removed completely. Should that not be possible it should be replaced with a processor that is transparent to its internal operation.
On the other hand, there have been people who have warned about the dangers of CPU vendors putting Management Engines in their products, which are outside of the control of end users (by design). One of those concerns was the ability to rig sales or even kill off second hand markets markets all together. Apparently, this have already become a reality now.
I'm not surprised it's sold as security feature, just as terrorism and child pornography have been magic words in other fields. But at the end of the day, vendors stand to substantially increase their control on sales and with it their profits, with features that may only be significant in edge cases. That smells a lot like an antitrust issue to me. That all vendors are likely try to move in this same direction, as an opportunity to make more profit, doesn't make it any less devious. All the more reason for antitrust investigators to start looking into this.
Yes. Consumer protections apply to everyone. Within Australia, those protections are considered the "bare minimum" that must be implemented by every business, across the board.
Certain industries have other protections they must implement atop of those.
I'm not even sure if the following is uniform across the EU, but I have always assumed (maybe even been told) that it is. Where I come from (The Netherlands), (afaik) when you do business with another business then consumer protection laws don't apply.
The rational appears to be that as a business you don't need the same kind of protection as a consumer. It's considered the risk of doing business, and companies suing each other in court (e.g. for fraud) is considered to be less unbalanced than it would be for private individual (consumer) against a company, in terms of (financial/legal) means.
In reality there probably are different (less savory) historical reasons behind it too, maybe even the preservation of the "natural power distribution" (euphemism for the already wealthy to stay that way) between smaller and larger businesses. That's at least how I have heard it being justified politically. Meanwhile, good luck suing a large company if you're a smaller business yourself. Either way, as I already implied, I think that's more or less by design.
Great if Australia is more egalitarian on that subject. If not for all of nature tring to kill me at every second there, I'd seriously consider immigrating over this xD
When you buy goods or services for your business which are:
+ under $40,000
+ over $40,000 and normally bought for personal, domestic or household use or consumption
+ vehicles and trailers used mainly to transport goods on public roads
your business will be considered a consumer and entitled to certain remedies under the consumer guarantees if something goes wrong.
---
As an EPYC CPU doesn't cost more than $40,000 per unit (closer to $8,000 from what I've found), it would fall under the guarantees.
Australian laws are still skewed in favour of the larger companies, but one place where the law tends not to fall down is consumer protections.
[0] https://www.accc.gov.au/business/business-rights-protections...
Intel has Boot Guard, AMD has this.
Either one may have seemed the better choice at one point in time, but it's clear they're really going down the same path.
First, somebody breaks into a server room, replaces the motherboard with a compromised one, and notices mid replacement that they forgot a processor. (Since the processor locks during first boot, it is of no use if the supply chain is compromised before the first boot. On the other hand, I would imagine somebody willing to break into a data center to replace a motherboard would also be willing to do all kinds of other shenanigans, like bringing another processor.)
The second scenario is, somebody thinks about buying a used instead of an new processor.
It’s actually easier to swap a mobo with a cpu and heatsink that’s already seated.
While if you can do this, you don't need to replace mother board/CPU anyway because you already pwned them and copy/modify the data whatever you want.
What security key? Do you mean the memory encryption key? We're talking about a powered off machine, so that's irrelevant.
The article talks about virtual machines as a subset of memory encryption. It also specifically says "ephemeral keys". Not ones that would be preserved across a shutdown.
What is encrypted on a powered-off server that the CPU knows the key to?
Because otherwise it's really hard why the website would claim that every end user would be enthused about these lock-ins. Sort of weird statement.