Reversing the AMD Secure Processor (PSP) – Part 2: Cryptographic Co-Processor(dayzerosec.com)
dayzerosec.com
Reversing the AMD Secure Processor (PSP) – Part 2: Cryptographic Co-Processor
https://dayzerosec.com/blog/2023/04/22/reversing-the-amd-secure-processor-psp-part-2-cryptographic-co-processor-ccp.html
30 comments
I never understood why AMD is not at least making the source of these available. I would actually really like a secure cryptographic processor that's been extensively vetted and trustworthy.
That's exactly what we're doing with OpenTitan: https://opentitan.org/
Which Google will be using in Chromebook for it's security chip https://lowrisc.org/news/nuvoton-develops-opentitan-based-se...
Which Google will be using in Chromebook for it's security chip https://lowrisc.org/news/nuvoton-develops-opentitan-based-se...
Very cool. Bookmarked.
They did publish the source:
https://github.com/amd/AMD-ASPFW
This was the PR(!): https://ir.amd.com/news-events/press-releases/detail/1154/am...
I wonder if the reported exploits forced them to publish the source.
This was the PR(!): https://ir.amd.com/news-events/press-releases/detail/1154/am...
I wonder if the reported exploits forced them to publish the source.
That is only the part that allows encrypted virtual machines on EPYC cpus. The PSP in some form is on all AMD processors since about 2013/2014.
Encrypted vm's? On epyc?
What's the performance penalty for that?
What's the performance penalty for that?
In benchmarks from Microsoft Azure and Google Cloud, 1-8% overhead for throughput.
Microsoft Azure: https://community.amd.com/t5/epyc-processors/microsoft-azure...
Google Cloud: https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
Microsoft Azure: https://community.amd.com/t5/epyc-processors/microsoft-azure...
Google Cloud: https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
For CPU bound work loads, pretty low, but not low enough that it's free (~5%).
For devices (especially latency sensitive workloads), it's quite bad. Device accesses have to be bounce-buffered. You can't do anything vaguely zero copy, since the device can't DMA to or from the VM. Future hardware support will mitigate that (mutually attested VM/Device interactions), but no real world devices support it yet.
For devices (especially latency sensitive workloads), it's quite bad. Device accesses have to be bounce-buffered. You can't do anything vaguely zero copy, since the device can't DMA to or from the VM. Future hardware support will mitigate that (mutually attested VM/Device interactions), but no real world devices support it yet.
I don't know the performance implications, but the brief description of the feature is that guest memory is encrypted with a key that the host doesn't know, so the host can't observe the contents of guest memory.
The common assumption is that their hands are tied on that matter.
Like OpenSIL, AMD could start a long-term project to replace the closed ASP with an open alternative. The industry now has Calpitra (AMD contributes), OpenTitan, TockOS (used by Pluton) and other open hardware and software projects for security enclaves.
Many believe it was not added as a result of customer requirements, but that the government leaned on them to add it as a tool of surveillance.
"AMD Confirms It Won't Opensource EPYC's Platform Security Processor Code" https://hothardware.com/news/amd-confirms-it-will-not-be-ope... (2017)
> Dr. Lisa Su gave some hope that something would be done when she said she'd discuss things internally as the result of a recent reddit AMA question. Ultimately, though, it turns out that AMD is not opening up the PSP
https://www.twitch.tv/videos/160097335?t=00h35m35s
> Dr. Lisa Su gave some hope that something would be done when she said she'd discuss things internally as the result of a recent reddit AMA question. Ultimately, though, it turns out that AMD is not opening up the PSP
https://www.twitch.tv/videos/160097335?t=00h35m35s
How popular is AMDs PSP, or Intels IME for that matter, in the real world. I've never seen either used at all.
There are several functionalities provided by these systems:
* System Control Processing. This means that the PSP / ME handle early boot (bringup) and peripheral management, especially in low-power and sleep modes. So from a "popularity" standpoint, 100% of systems with these processors are using them for this reason alone.
* Firmware TPM (AMD fTPM / Intel PTT). This provides the Trusted Platform Module API using a Trusted Application running in the management engine, rather than a dedicated TPM chip. It's commonly used with Windows for BitLocker, especially on AMD platforms, and Linux users who like keeping their disks secure will use it as well. It's less vulnerable to bus snooping attacks, since on AMD it's embedded in the CPU package and on Intel nobody's reverse engineered the bus interface between the PCH and the CPU to see if key extraction is possible like it is for unencrypted standalone TPM. TPM also has other uses, like Secure Boot measurement attestation (hashes) and arbitrary key enrollment, which are of course also provided by fTPM when available. From a popularity standpoint this is used on 100% of modern AMD systems running Windows 11.
* Virtual Machine encryption/isolation (AMD SEV for example).
* Widevine L1 video DRM support on Chromebooks. I think it might also be used for PlayReady on Windows, but I'm less familiar with this system.
* Custom TrustApps. AMD PSP provides a standard GlobalPlatform / ARM TEE (Trusted Application Environment). I'm not aware of anyone besides Google (Chromebooks use it for trusted boot, SecureDebug validation, Widevine, etc.) actively using it in widespread deployment yet, but I'm sure someone is working on it. It has application basically anywhere Intel SGX was used, for example, for secure / segregated key management, data processing, etc. (Signal use SGX extensively for this).
* Remote management (Intel vPro). This is the thing that causes people to freak out about Intel ME. It's somewhat popular in enterprise beige-laptop deployments, although it's limited to network interfaces with driver support in the ME firmware (Intel Ethernet and WiFi). Arguably more bug-ridden and horrible external third-party management engines like iDRAC are still more popular in the datacenter.
* System Control Processing. This means that the PSP / ME handle early boot (bringup) and peripheral management, especially in low-power and sleep modes. So from a "popularity" standpoint, 100% of systems with these processors are using them for this reason alone.
* Firmware TPM (AMD fTPM / Intel PTT). This provides the Trusted Platform Module API using a Trusted Application running in the management engine, rather than a dedicated TPM chip. It's commonly used with Windows for BitLocker, especially on AMD platforms, and Linux users who like keeping their disks secure will use it as well. It's less vulnerable to bus snooping attacks, since on AMD it's embedded in the CPU package and on Intel nobody's reverse engineered the bus interface between the PCH and the CPU to see if key extraction is possible like it is for unencrypted standalone TPM. TPM also has other uses, like Secure Boot measurement attestation (hashes) and arbitrary key enrollment, which are of course also provided by fTPM when available. From a popularity standpoint this is used on 100% of modern AMD systems running Windows 11.
* Virtual Machine encryption/isolation (AMD SEV for example).
* Widevine L1 video DRM support on Chromebooks. I think it might also be used for PlayReady on Windows, but I'm less familiar with this system.
* Custom TrustApps. AMD PSP provides a standard GlobalPlatform / ARM TEE (Trusted Application Environment). I'm not aware of anyone besides Google (Chromebooks use it for trusted boot, SecureDebug validation, Widevine, etc.) actively using it in widespread deployment yet, but I'm sure someone is working on it. It has application basically anywhere Intel SGX was used, for example, for secure / segregated key management, data processing, etc. (Signal use SGX extensively for this).
* Remote management (Intel vPro). This is the thing that causes people to freak out about Intel ME. It's somewhat popular in enterprise beige-laptop deployments, although it's limited to network interfaces with driver support in the ME firmware (Intel Ethernet and WiFi). Arguably more bug-ridden and horrible external third-party management engines like iDRAC are still more popular in the datacenter.
It's mentioned in part 1 of this post, that the PSP is what actually boots the processor (among other things, it sets up the memory controller), so it's used in the real world every time you turn on your AMD-based computer.
In addition to system launch integrity, they are likely used by streaming video DRM, e.g. Netflix.
SGX was used by video DRM on intel platforms. As SGX no longer exists in modern intel processors, its not really doable anymore. netflix drm and the like are probably done on gpu, not on cpu (but I could be wrong)
It's actually impossible to have a "legal"/commercial 4k bluray setup today on modern PCs/CPUs, as they will only license it to players that can use SGX and as noted SGX no longer exists. (of course this doesn't prevent one from using vlc / libaacs and the like).
It's actually impossible to have a "legal"/commercial 4k bluray setup today on modern PCs/CPUs, as they will only license it to players that can use SGX and as noted SGX no longer exists. (of course this doesn't prevent one from using vlc / libaacs and the like).
I believe Xeons still include SGX even today. You’re correct about the consumer CPUs not supporting it anymore.
Any idea why Xeons would still contain this feature? Is it for backwards compatibility for their corporate customers or are there reasons that someone would still use it in modern applications in 2024?
The protected video path for Intel integrated GPUs involves the ME.
my guess is that its not used by the ARC dGPUs which have their own equivalent for it? But I guess it makes sense to use it for iGPUs.
With that said, seems sketchy to send untrusted data to the ME which is essentially an independent computer, running an independent OS with the ability to have persistent state. Seems like a security failure waiting to happen.
With that said, seems sketchy to send untrusted data to the ME which is essentially an independent computer, running an independent OS with the ability to have persistent state. Seems like a security failure waiting to happen.
Ah, I always understood them to be mostly for remote management.
That's AMT/vPro in Intels case. Gives you things like vnc access from the moment the machine turns on.
the PSP is on every single AMD SoC (probably going back 10 years now).
Signal Private Messenger built private contact discovery and secure value recovery using Intel Software Guard eXtensions (SGX), similar to AMD Secure Memory Encryption (both usually used for DRM).
https://signal.org/blog/private-contact-discovery/ (2017) https://signal.org/blog/secure-value-recovery/ (2019)
Intel SGX is mostly orthogonal to Intel IME but each is an additional attack surface with enough privilege/persistence to assist attacks on the other.
https://signal.org/blog/private-contact-discovery/ (2017) https://signal.org/blog/secure-value-recovery/ (2019)
Intel SGX is mostly orthogonal to Intel IME but each is an additional attack surface with enough privilege/persistence to assist attacks on the other.
(genuine question, sorry -) is it just me or does anyone else have problems reading the text with the font the webpage uses? It kinda blurs away from "text" into kind of a grey block. I think it might be the very small vertical line to line spacing?
It's the contrast!, all the code blocks do not meet the WCAG standards for accessible text, especially the second one, which as the hardest one for me to read.
Author of the site here (though not this specific post).
Any chance you could take a screenshot of what your seeing? The other commenter mentioned the contract of comment s in code blocks which I've already noted to fix.
Any chance you could take a screenshot of what your seeing? The other commenter mentioned the contract of comment s in code blocks which I've already noted to fix.
> Any chance you could take a screenshot of what your seeing?
I don't think it's a rendering issue, but sure: https://postimg.cc/ygsNzMhX
I looked into the CSS and removing the "line-height:1.15" makes it massively more readable for me personally. I have no idea about any science of human perception but I think the font is too "dense" with that reduced line spacing. (It's hard to self-observe this but I believe my eyes are slipping off between lines. Character width might be a factor too.)
(To clarify, my issue is with the main text itself, not code blocks.)
I don't think it's a rendering issue, but sure: https://postimg.cc/ygsNzMhX
I looked into the CSS and removing the "line-height:1.15" makes it massively more readable for me personally. I have no idea about any science of human perception but I think the font is too "dense" with that reduced line spacing. (It's hard to self-observe this but I believe my eyes are slipping off between lines. Character width might be a factor too.)
(To clarify, my issue is with the main text itself, not code blocks.)