AMD EPYCs haben Mainboard-Lock wenn die Hersteller es wollen

Wie Ser­ve­The­Home und auch eini­ge fest­stel­len muss­ten, gibt es ein bis­her nicht bedach­tes “Fea­ture” bei den AMD EPYC CPUs der 7001er und 7002er Serie:

Die Main­board-Her­stel­ler kön­nen die CPUs auf ihren Boards sper­ren. Es soll der Sicher­heit des Sys­tems dienen.

Wor­um es geht:
Man steckt einen fabrik-neu­en EPYC in ein DELL Board und star­tet das Sys­tem. Beim ers­ten Start brennt sich eine Ein­mal-Siche­rung in die CPU und danach star­tet die CPU nur noch in DELL Boards mit ent­spre­chend signier­tem BIOS. Steckt man danach jedoch die CPU zB in ein ASUS oder ASRock Board star­tet die CPU nicht, die CPU stellt sich tot, bis die­se wie­der in ein DELL Board kommt. Auch Hew­lett-Packard Enter­pri­se soll dies haben.


The AMD Plat­form Secu­re Boot Fea­ture (PSB) is a miti­ga­ti­on for firm­ware Advan­ced Per­sis­tent Thre­ats. It is a defen­se-in-depth fea­ture. PSB extends AMD’s sili­con root of trust to pro­tect the OEM’s BIOS.  This allows the OEM to estab­lish an unbro­ken chain of trust from AMD’s sili­con root of trust to the OEM’s BIOS using PSB, and then from the OEM’s BIOS to the OS Boot­loa­der using UEFI secu­re boot. This pro­vi­des a very power­ful defen­se against remo­te atta­ckers see­king to embed mal­wa­re into a platform’s firmware.

An OEM who trusts only their own cryp­to­gra­phi­cal­ly signed BIOS code to run on their plat­forms will use a PSB enab­led mother­board and set one-time-pro­gramm­a­ble fuses in the pro­ces­sor to bind the pro­ces­sor to the OEM’s firm­ware code signing key. AMD pro­ces­sors are ship­ped unlo­cked from the fac­to­ry, and can initi­al­ly be used with any OEM’s mother­board. But once they are used with a mother­board with PSB enab­led, the secu­ri­ty fuses will be set, and from that point on, that pro­ces­sor can only be used with mother­boards that use the same code signing key. (Source: AMD state­ment to STH)


Pro­blem daraus:
Solan­ge man die CPUs inner­halb einer Fir­ma wan­dern lässt (zB inner­halb DELL-Sys­te­me oder HPE-Sys­te­me) funk­tio­niert es. Will man aber eine CPU aus einem sol­chen Sys­tem zie­hen und die­se in ande­re Sys­te­me ste­cken (oder wei­ter­ver­kau­fen) star­ten die CPUs nicht mehr.

Für die Sicher­heit des gesam­ten Sys­tems ist dies gut — für den Zweit­markt und die Umwelt ist dies nicht gut!

Update 1:
Die EYPC stel­len sich nicht tot son­dern star­ten an und hän­gen mit dem POST-Code 78
Im STH Forum gibt es ein Thread hier­zu

DELL schreibt hier­zu in der ver­link­ten PDF:

The first genera­ti­on of the AMD EPYC pro­ces­sors have the AMD Secu­re Pro­ces­sor – an inde­pen­dent pro­ces­sor core inte­gra­ted in the CPU packa­ge along­side the main CPU cores. On sys­tem power-on or reset, the AMD Secu­re Pro­ces­sor exe­cu­tes its firm­ware while the main CPU cores are held in reset. One of the AMD Secu­re Processor’s tasks is to pro­vi­de a secu­re hard­ware root-of-trust by authen­ti­ca­ting the initi­al PowerEdge BIOS firm­ware. If the initi­al PowerEdge BIOS is cor­rup­ted or com­pro­mi­sed, the AMD Secu­re Pro­ces­sor will halt the sys­tem and pre­vent OS boot. If no cor­rup­ti­on, the AMD Secu­re Pro­ces­sor starts the main CPU cores, and initi­al BIOS exe­cu­ti­on begins.
The very first time a CPU is powe­red on (typi­cal­ly in the Dell EMC fac­to­ry) the AMD Secu­re Pro­ces­sor per­ma­nent­ly stores a uni­que Dell EMC ID insi­de the CPU. This is also the case when a new off-the-shelf CPU is instal­led in a Dell EMC ser­ver. The uni­que Dell EMC ID insi­de the CPU binds the CPU to the Dell EMC ser­ver. Con­se­quent­ly, the AMD Secu­re Pro­ces­sor may not allow a PowerEdge ser­ver to boot if a CPU is trans­fer­red from a non-Dell EMC ser­ver (and CPU trans­fer­red from a Dell EMC ser­ver to a non-Dell EMC ser­ver may not boot). AMD EPYC Genera­ti­on 2 pro­ces­sors also offer the AMD Secu­re Pro­ces­sor — for cryp­to­gra­phic func­tio­n­a­li­ty for secu­re key genera­ti­on and key manage­ment. This pro­vi­des full stack encryp­ti­on without any over­head for the pro­ces­sor. In addi­ti­on, for hard­ware-acce­le­ra­ted memo­ry encryp­ti­on for data-in-use pro­tec­tion, the secu­ri­ty com­pon­ents in Rome pro­ces­sors inclu­de the AES-128 encryp­ti­on engi­ne, which is embed­ded in the memo­ry con­trol­ler and auto­ma­ti­cal­ly encrypts and decrypts data in main memo­ry with an appro­pria­te key.

Update 2:
Hew­lett Packard Enter­pri­se ist doch nicht betrof­fen — HPE löst dies anders als DELL über ihre eige­nen BMC Chips statt über die PSP in den EPYC und brennt sich daher nicht in die EPYC rein wie DELL.

HPE cla­ri­fied that they are doing this in a dif­fe­rent man­ner than Dell after initi­al­ly con­fir­ming that they were using the AMD PSB fea­ture. After this went live, HPE sent us the following:

HPE does not use the same secu­ri­ty tech­ni­que that Dell is using for a BIOS hard­ware root of trust. HPE does not burn, fuse, or per­ma­nent­ly store our public key into AMD pro­ces­sors which ship with our pro­ducts. HPE uses a uni­que approach to authen­ti­ca­te our BIOS and BMC firm­ware: HPE fuses our hard­ware – or sili­con – root of trust into our own BMC sili­con to ensu­re only authen­ti­ca­ted firm­ware is exe­cu­t­ed. Thus, while we imple­ment a hard­ware root of trust for our BIOS and BMC firm­ware, the pro­ces­sors that ship with our ser­vers are not locked to our plat­forms. (Source: HPE)

Quel­le / Links:
STH Arti­kel dazu (engl.)
STH Video dazu (engl.)
DELL Info PDF hier­zu (engl.)