Hacker News Reader

Comment by soneil | Hacker News Reader

If they’re setting OTP on the die, all AMD could offer would be a warranty replacement at best. There’s no etching new fuses into a packaged die.

View on HN

They could blow the key to an "insecure" state, and then have a jumper on the motherboard to allow insecure booting.

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:

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.

Double plus if it's for an environmental cause. That would be a PR disaster.

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.

Reply on news.ycombinator.com