|
|
|
|
|
|
by emily-c
2414 days ago
|
|
|
The CSME is on the PCH[1] (when one exists). (However AMD elected to put their PSP on-die as an IP-block). It is the root of trust of the system and takes the CPU out of reset even though it's not on the CPU itself. x86-based machines have pretty much always had multiple auxiliary processors/SoCs that control various aspects of the system such as the embedded controller (a direct descendant of the 8042 keyboard controller). Another example of this is the AMD SMU which lives on the chipset and coexists with the PSP (the talk in the link gets code running on this as you described)[2]. Interestingly the Chromebook EC firmware is open source[3]. Joanna Rutkowska has done a nice overview of some of the security aspects of these topics as well[4]. Ideally there would be a standard way to verify and measure all the various firmware images (and potentially option ROMs which would be theoretically measured with SRTM via UEFI) for these system processors during boot during a DRTM event (with Intel's STM/AMD SMM supervisor enabled as well) but there is a long way to go for that. [1] https://i.blackhat.com/USA-19/Wednesday/us-19-Hasarfaty-Behi... [2] https://www.youtube.com/watch?v=iYvhHey_dTk [3] https://chromium.googlesource.com/chromiumos/platform/ec/+/m... [4] https://www.youtube.com/watch?v=rcwngbUrZNg |
|
|
> an “external ME” would be just fine running without a CPU socketed in at all
and made Ryzen a nearly-SoC, EPYC an actual SoC (no chipset at all required AFAIK). (To be fair Intel did integrate many things onto the die as well..)
https://fuse.wikichip.org/news/1177/amds-zen-cpu-complex-cac... seems to confirm that SMUs are on-die at least on EPYC.
> Interestingly the Chromebook EC firmware is open source
And even the Google Security Chip is included under that. You can't run a customized GSC firmware on a production device unless you have Google's keys, but you can look — and hopefully maybe reproduce the build?