Which Google will be using in Chromebook for it's security chip https://lowrisc.org/news/nuvoton-develops-opentitan-based-se...
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.
> 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
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.
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.)
* 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 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).
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.
What's the performance penalty for that?
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 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.
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.