Techpowerup has an additional Q&A concerning the alleged exploits.
https://www.techpowerup.com/242386/cts-labs-responds-to-a-techpowerup-technical-questionnaire
This seems to clarify that persistence is generally related to the off-chip flash memory used by the PSP to store the alterable portions of its firmware and software. That may mean a fresh motherboard could be the upper end of what is needed to be sure a BIOS compromise is avoided, if there's uncertainty about whether a compromised PSP could somehow interfere with an attempt to rewrite the flash.
I would think even then there could be some in-CPU fuses or similar structures to that could be wrecked by an attack program.
The first section on the BIOS exploit points to AMD's firmware signature check authenticating at an early point, and that authentication either covers a subset of the code the PSP loads or somehow the initial check's result somehow applies to a broader range of code that can include hostile code. The description, if accurate, indicates the PSP checks the beginning of its firmware and the exploit occurs in the next step where secondary modules are loaded. I would expect those to be signed as well, so perhaps a bug in their checks, a missing bounds check, or time window for replacing part of their payload after the signature check is what allows unsigned code to get in.
The ideal outcome AMD's general description of its secure platform describes is that tampering with the main firmware or the PSP's modules is that the PSP would halt the process and the CPU would not exit the mostly halted startup state.
The other exploit that requires a signed driver doesn't need the driver itself to be modified by a hostile actor and signed with a vendor's key. The signed driver's importance is that it is granted IO space access by the OS, and then can be manipulated into triggering back doors in the ASMedia hardware/firmware. I had thought AMD's own IOMMU and PSP served to create a thicker layer of isolation, or could if the SOC's programmable elements are tweaked to use their ability to intercept or redirect accesses to the backdoor. I would have thought existing IO virtual management would limit what the hacked DMA unit could look at.
The researchers feigned surprise that AMD hasn't responded to them in a few days, citing that another lab got back to them in a shorter time. This seems disingenuous. An outside lab doesn't need to be that thorough and doesn't have the legal concerns, obligations, and responsibilities that AMD would have.
https://www.techpowerup.com/242386/cts-labs-responds-to-a-techpowerup-technical-questionnaire
This seems to clarify that persistence is generally related to the off-chip flash memory used by the PSP to store the alterable portions of its firmware and software. That may mean a fresh motherboard could be the upper end of what is needed to be sure a BIOS compromise is avoided, if there's uncertainty about whether a compromised PSP could somehow interfere with an attempt to rewrite the flash.
I would think even then there could be some in-CPU fuses or similar structures to that could be wrecked by an attack program.
The first section on the BIOS exploit points to AMD's firmware signature check authenticating at an early point, and that authentication either covers a subset of the code the PSP loads or somehow the initial check's result somehow applies to a broader range of code that can include hostile code. The description, if accurate, indicates the PSP checks the beginning of its firmware and the exploit occurs in the next step where secondary modules are loaded. I would expect those to be signed as well, so perhaps a bug in their checks, a missing bounds check, or time window for replacing part of their payload after the signature check is what allows unsigned code to get in.
The ideal outcome AMD's general description of its secure platform describes is that tampering with the main firmware or the PSP's modules is that the PSP would halt the process and the CPU would not exit the mostly halted startup state.
The other exploit that requires a signed driver doesn't need the driver itself to be modified by a hostile actor and signed with a vendor's key. The signed driver's importance is that it is granted IO space access by the OS, and then can be manipulated into triggering back doors in the ASMedia hardware/firmware. I had thought AMD's own IOMMU and PSP served to create a thicker layer of isolation, or could if the SOC's programmable elements are tweaked to use their ability to intercept or redirect accesses to the backdoor. I would have thought existing IO virtual management would limit what the hacked DMA unit could look at.
The researchers feigned surprise that AMD hasn't responded to them in a few days, citing that another lab got back to them in a shorter time. This seems disingenuous. An outside lab doesn't need to be that thorough and doesn't have the legal concerns, obligations, and responsibilities that AMD would have.
