> How would the GPU verify it's speaking to a real TPM?
Option 1: as I said, the GPU could have its own, and yes in that case the EK cert would be known to the GPU (or it could have a platform-like cert issued by the GPU OEM).
Option 2: the platform vendor can teach the GPU the EK cert (or the public key for some primary key anyways).
Option 3: the GPU could learn it on first use.
> charitably let's say that's a signed blob that the driver pushes in at startup
That's what TPM vendors do as to the EK cert. Surely if they can do that then so can GPU and platform vendors. Indeed, some platform vendors ship with platform certs.
> but that's still going to be a terrible user experience because you won't get media playback if your machine has a TPM that's too new or .
What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops.
As to "from too niche a vendor", as long as the platform vendor teaches the GPU what the EK cert is, or makes a platform-like cert that the GPU can use to authenticate the TPM, then it's good enough.
Anyways I suspect that MSFT and others don't mind an incrementalist approach. You have a system that can do it their way? Great, it will. You have a system that cannot do it their way? Fine, they'll do weak software DRM for now. There's probably no other way to to get to their dream DRM everywhere state.
> What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops.
I buy a GPU in 2025. I buy a new motherboard in 2026 and plug the GPU into it. How does the GPU learn about the new EK CA? These are devices that can be moved between systems, you can't delegate this to the platform vendor or TOFU, the GPU would need to generate independent trust in the TPM.
One way I might handle this would be to have a TPM on the GPU itself. Then you can move the GPU about all you like, and it will work. The GPU would have to implement an API and protocol that allows the DRM site to do attestation via software running on the CPU, but that seems doable.
The other way would be accept that the GPU that the content is to be played on might not be the same as the device on which the TPM exists. You could have the GPU on a computer halfway around the world and use a TPM from another system to which the user account is registered on the DRM site. Not great, but as a form of account sharing and subject to account sharing detection, it's not bad.
Well of course. My comment was about how TPMs could be used but how still you were correct that TPMs aren't the FSF's enemy. I was exploring that space to further show that.
Option 1: as I said, the GPU could have its own, and yes in that case the EK cert would be known to the GPU (or it could have a platform-like cert issued by the GPU OEM).
Option 2: the platform vendor can teach the GPU the EK cert (or the public key for some primary key anyways).
Option 3: the GPU could learn it on first use.
> charitably let's say that's a signed blob that the driver pushes in at startup
That's what TPM vendors do as to the EK cert. Surely if they can do that then so can GPU and platform vendors. Indeed, some platform vendors ship with platform certs.
> but that's still going to be a terrible user experience because you won't get media playback if your machine has a TPM that's too new or .
What do you mean "too new"? Like, you replaced your TPM? That's a thing on servers, but not laptops.
As to "from too niche a vendor", as long as the platform vendor teaches the GPU what the EK cert is, or makes a platform-like cert that the GPU can use to authenticate the TPM, then it's good enough.
Anyways I suspect that MSFT and others don't mind an incrementalist approach. You have a system that can do it their way? Great, it will. You have a system that cannot do it their way? Fine, they'll do weak software DRM for now. There's probably no other way to to get to their dream DRM everywhere state.