3 ms·

I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secr

I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. This is the case for Nvidia, for Apple M1s, etc; the OS never has to touch plaintext HDCP keys, and this has nothing to do with open source drivers. Can you clarify what you mean exactly? I have a hard time believing AMD ever ran HDCP keys through the Windows kernel.

bayindirh 5y ago
> I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card. AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used. This is something to praise for, IMHO.
- marcan_42 5y ago
  I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail? Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.
  - bayindirh 5y ago
    In their previous setup, as per their word, it was impossible to access video decoders and related machinery without exposing some HDCP stuff, incl. the key related storage and other secret stuff. So, they were unable to provide the access they wanted to provide (for video decoders, at least), on the previous (then current) architecture.
    - marcan_42 5y ago
      That's... very weird. What would that expose? If you can read the keys at all from the OS, directly or indirectly, that's a security flaw. AFAIK AMD GPUs have supported video decode on Linux across all generations, so what was unavailable?
      - bayindirh 5y ago
        Considering the history of ATI with video, and how they enabled GL shaders to work with video acceleration, post processing and effects before anyone was able to dream this thing (Readeon 8500 was able to use shaders to post-process and apply effects to the video), I think their silicon layout was very convoluted and unconventional for today's standards. Considering HDCP came later, it might have just been slapped as a side module and some of their math magic might be offloaded to GPU even. I remember having old ATI drivers having a very cinematic look when video was accelerated by the GPU itself (it was surreally beautiful), but they had to throw all this machinery out from the driver when they started to modernize their stack (and they broke video playback for months due to not supporting proper overlay formats). Similarly, I think closed source drivers were programming some of the cards during initialization, because I remember they're talking about moving all this init step to the BIOS itself, and opening some doors on the BIOS to tweak the card during the init (clocks, fans, temp reads, etc. IIRC) for allowing OS and open drivers to play nicer and with less effort with the cards in the long run. The details are hazy, because these transitions were made almost a decade ago if not longer. However, while NVIDIA was playing the deaf, and Intel was just starting to provide good open drivers for their IGPs, AMDs move as a prime GPU vendor brought a lot of good light to them. If you want, I can try to dig the history and create a timeline for you, but it might not be an immediate endeavor.

bayindirh 5y ago

> I don't think any GPU vendor has ever had HDCP secrets exposed to the OS. That'd be terrible security; you'd need mandatory OS secure boot to keep the keys secret. Yes, I'd not argue with that, I also never wanted or implied that I shall be able to get said keys from the card. AMD/ATI back in the day said that, they have intentionally coupled video decoders, related logic and HDCP to same IP block for performance and silicon real-estate reasons, but in order to keep their promises about open drivers and accessible hardware, starting with (then) next generation silicon, they'll move all HDCP stuff to another IP. In turn, they will allow unfettered access to all GPU including 3D and video related features sans HDCP. However, with that architecture, even open drivers can use HDCP related hardware and functions without compromising the security and licensing around it, as a result allowing identical experience and freedom (from a developer standpoint) regardless of the driver used. This is something to praise for, IMHO.

marcan_42 5y ago
I still don't really understand how this is relevant for the drivers. Even if HDCP is part of another IP block, that doesn't mean open drivers can't use it. That's just an implementation detail. You can use HDCP on any platform the same way the proprietary drivers would (if you implement the right knobs to control it). Do you have a reference with more detail? Ultimately the open driver should always be able to do all the same things the closed driver does and get the same result. If there are any secrets in the closed driver that "can't" be exposed, that's a security flaw in the design.
- bayindirh 5y ago
  In their previous setup, as per their word, it was impossible to access video decoders and related machinery without exposing some HDCP stuff, incl. the key related storage and other secret stuff. So, they were unable to provide the access they wanted to provide (for video decoders, at least), on the previous (then current) architecture.
  - marcan_42 5y ago
    That's... very weird. What would that expose? If you can read the keys at all from the OS, directly or indirectly, that's a security flaw. AFAIK AMD GPUs have supported video decode on Linux across all generations, so what was unavailable?
    - bayindirh 5y ago
      Considering the history of ATI with video, and how they enabled GL shaders to work with video acceleration, post processing and effects before anyone was able to dream this thing (Readeon 8500 was able to use shaders to post-process and apply effects to the video), I think their silicon layout was very convoluted and unconventional for today's standards. Considering HDCP came later, it might have just been slapped as a side module and some of their math magic might be offloaded to GPU even. I remember having old ATI drivers having a very cinematic look when video was accelerated by the GPU itself (it was surreally beautiful), but they had to throw all this machinery out from the driver when they started to modernize their stack (and they broke video playback for months due to not supporting proper overlay formats). Similarly, I think closed source drivers were programming some of the cards during initialization, because I remember they're talking about moving all this init step to the BIOS itself, and opening some doors on the BIOS to tweak the card during the init (clocks, fans, temp reads, etc. IIRC) for allowing OS and open drivers to play nicer and with less effort with the cards in the long run. The details are hazy, because these transitions were made almost a decade ago if not longer. However, while NVIDIA was playing the deaf, and Intel was just starting to provide good open drivers for their IGPs, AMDs move as a prime GPU vendor brought a lot of good light to them. If you want, I can try to dig the history and create a timeline for you, but it might not be an immediate endeavor.