Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Adds Support for EGL Protected Surfaces Using AMDGPU TMZ

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RadeonSI Gallium3D Adds Support for EGL Protected Surfaces Using AMDGPU TMZ

    Phoronix: RadeonSI Gallium3D Adds Support for EGL Protected Surfaces Using AMDGPU TMZ

    Landing in Mesa 20.3 during this final week of feature development is support in RadeonSI Gallium3D for EGL_EXT_protected_surface. This long-standing EGL extension allows surfaces/windows to beset as protected and in which case the contents are only accessible to secure accesses. Outside/insecure accesses to the window (surface) contents are blocked...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    My Raven system finally has working TMZ support since a firmware update sorted the amd-tee stuff

    Comment


    • #3
      Does anyone of you have some sources maybe rumours how the plan of Netflix and Amazon etc are to make 4k Streams legally feasible on Linux (not android)? Even proper FullHD for Amazon would already be a step forward.

      Comment


      • #4
        I do not want this. How can I disable this?
        Is it possible to have this extension appear as supported but really not be implemented?

        Comment


        • #5
          Originally posted by uid313 View Post
          Is it possible to have this extension appear as supported but really not be implemented?
          Likely you can, but that wouldn't make much sense: the idea is to do whole decryption in a "secure" (from the user) environment, thus entire decoding and display pipeline should be done in encrypted memory inaccessible to the host system. If you fake presence of protected surface support, best case you'll get garbage instead of an image on the screen (because of an attempt to display said encrypted memory without decryption stage), worst case depends on a stub implementation.
          Last edited by klokik; 02 November 2020, 04:13 PM. Reason: Better wording

          Comment


          • #6
            Originally posted by klokik View Post

            Likely you can, but that wouldn't make much sense: the idea is to do whole decryption in a "secure" (from the user) environment, thus whole decoding and display pipeline should be done in encrypted memory inaccessible the host system. If you fake presence of protected surface support, best case you'll get garbage instead of image on the screen (because of an attempt to display said encrypted memory without decoding stage), worst case depends on a stub implementation.
            Technically nothing prevents you from rewriting the extension using non-encrypted memory, and fake the "encrypted" decode API the entire way up.

            Comment


            • #7
              I'm happy to see this feature.

              Everyone who doesn't want it, you can choose not to use it.

              Comment


              • #8
                Originally posted by Serafean View Post

                Technically nothing prevents you from rewriting the extension using non-encrypted memory, and fake the "encrypted" decode API the entire way up.
                problem is, the content you get is already encrypted.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  I do not want this.
                  if you don't want to watch netflix, just don't pay for it, problem solved

                  Comment


                  • #10
                    Remember that every part of your computer is a tiny computer on its own, doing stuff you didn't tell it to since you powered it on for the first time. All encrypted, of course--but not by you. Exposing it on software is definitely not a big deal.

                    Comment

                    Working...
                    X