[HN Gopher] Reversing the AMD Secure Processor (PSP) - Part 2: C...
       ___________________________________________________________________
        
       Reversing the AMD Secure Processor (PSP) - Part 2: Cryptographic
       Co-Processor
        
       Author : vngzs
       Score  : 99 points
       Date   : 2024-08-13 16:34 UTC (3 days ago)
        
 (HTM) web link (dayzerosec.com)
 (TXT) w3m dump (dayzerosec.com)
        
       | dtx1 wrote:
       | 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.
        
         | DaSHacka wrote:
         | The common assumption is that their hands are tied on that
         | matter.
        
           | transpute wrote:
           | 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.
        
         | rajeshr wrote:
         | 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.
        
           | shrubble wrote:
           | 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.
        
             | tonetegeatinst wrote:
             | Encrypted vm's? On epyc?
             | 
             | What's the performance penalty for that?
        
               | toast0 wrote:
               | 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.
        
               | bobbiechen wrote:
               | 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...
        
               | strstr wrote:
               | 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.
        
         | shrubble wrote:
         | 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.
        
         | gchadwick wrote:
         | 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...
        
           | bn-l wrote:
           | Very cool. Bookmarked.
        
         | password4321 wrote:
         | "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
        
       | mrweasel wrote:
       | How popular is AMDs PSP, or Intels IME for that matter, in the
       | real world. I've never seen either used at all.
        
         | transpute wrote:
         | In addition to system launch integrity, they are likely used by
         | streaming video DRM, e.g. Netflix.
        
           | mrweasel wrote:
           | Ah, I always understood them to be mostly for remote
           | management.
        
             | iforgotpassword wrote:
             | That's AMT/vPro in Intels case. Gives you things like vnc
             | access from the moment the machine turns on.
        
           | compsciphd wrote:
           | 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).
        
             | jrpelkonen wrote:
             | I believe Xeons still include SGX even today. You're
             | correct about the consumer CPUs not supporting it anymore.
        
             | mjg59 wrote:
             | The protected video path for Intel integrated GPUs involves
             | the ME.
        
         | cesarb wrote:
         | 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.
        
         | almostgotcaught wrote:
         | the PSP is on every single AMD SoC (probably going back 10
         | years now).
        
         | bri3d wrote:
         | 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.
        
         | password4321 wrote:
         | 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.
        
       | eqvinox wrote:
       | (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?
        
         | zote wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2024-08-16 23:00 UTC)