"It then reads the initial block of the firmware (the Initial Boot Block, or IBB) into RAM (or, well, cache, as previously described) and parses it. There's a b

"It then reads the initial block of the firmware (the Initial Boot Block, or IBB) into RAM (or, well, cache, as previously described) and parses it. There's a block that contains a public key - it hashes that key and verifies that it matches the SHA256 from the fuses. It then uses that key to validate a signature on the IBB. If it all checks out, it executes the IBB and everything starts looking like the nice simple model we had before." Should all be performed by ME/PSP now, but the Intel ME/AMD PSP can't be updated (even with new microcode) and older versions are known to contain serious vulnerabilities. Thus we can reduce all of our options down to either (a) not running with Secure Boot or (b) running with Secure Boot, but only on the very latest Intel/AMD processors. So if we have the very latest processors, then we only need to worry about validating "critical" microcode updates to them and that doesn't need to happen at power-on at all, it can happen in the ME/PSP, but we do need to know about them at the C-suite level, since it will impact purchasing of replacement gear, financial statements and risk analysis decisions. That means we should power-on directly into the on-die ME/PSP and it, in turn, can bring up the RAM, PCI, etc. and check (online or on attached storage) for "critical" updates and, if found, emit a "distress beacon" on the network while also checking for a signal (from a resistor, the network or attached storage) that will inform it to download and update (rather than simply halting) the processor. This allows Management (the ones who have to sign SarBox, not just the system admins) to be informed of emerging vulnerabilities in their infrastructure (because of the "distress beacons" triggering indicators on their enterprise dashboards) so that they may choose to take explicit action to allow processing to continue (by emitting the signal that all ME/PSP would look for to enable critical microcode updates instead of halting). Likewise, we need ME/PSP to also start verifying all connected communication interfaces (before and after boot) by checking digital signatures that chip manufacturers obtain from Intel/AMD --much like what developers have to do to get their code to run in kernel space on an Apple Mac. I mean, CVE-2022-21742, et. al. --not just Thunderbolt and USB attacks. The only other rational solution really is to run with Secure Boot disabled (because older Intel/AMD processors cannot be trusted anyway --thanks to their non-updatable components like ME/PSP-- even with post-production microcode updates, even with Secure Boot). Anyway, 11 years later, will leave this here .. https://www.extremetech.com/defense/133773-rakshasa-the-hardware-backdoor-that-china-could-embed-in-every-computer https://www.extremetech.com/defense/133773-rakshasa-the-hard...