Announcement

Collapse
No announcement yet.

AMD's Crypto Co-Processor Driver Adds Green Sardine Support In Linux 5.13

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

  • AMD's Crypto Co-Processor Driver Adds Green Sardine Support In Linux 5.13

    Phoronix: AMD's Crypto Co-Processor Driver Adds Green Sardine Support In Linux 5.13

    The crypto subsystem updates have landed in the Linux 5.13 kernel...

    https://www.phoronix.com/scan.php?pa...ux-5.13-Crypto

  • #2
    I am still waiting for being able to use the CCP in my 3900X w/ Aorus Pro X570 for offloading crypto algorithms. The CCP driver complains about my BIOS not properly setting up the device and it refuses to work. The device seems to be working just fine on Windows (which makes me think that the BIOS has nothing to do with it), hence suggesting that the Linux driver needs a few more touchups.

    Comment


    • #3
      Originally posted by kiffmet View Post
      I am still waiting for being able to use the CCP in my 3900X w/ Aorus Pro X570 for offloading crypto algorithms. The CCP driver complains about my BIOS not properly setting up the device and it refuses to work. The device seems to be working just fine on Windows (which makes me think that the BIOS has nothing to do with it), hence suggesting that the Linux driver needs a few more touchups.
      after reading your comment I was searching for performance numbers ....this ccp is really fast. Is e.g. openssl using it automatically once the driver correctly recognizes the driver? What else in the daily linux desktop (server) use case is already supported out of the box?

      Comment


      • #4
        Green Sardine? Red Herring?
        Either way, while I like ASIC-style stuff for offloading certain specific tasks (very fast execution at low power consumption, CPU cycles saved) I am still reluctant when it comes to black boxes. Especially for sensitive stuff like cryptography.

        I mean, would you write a letter and then hand it to some obscure person sitting inside a letterbox to crypt it and then hand the crypted letter back out through the little opening? Sounds scary to me. And you don't even have a faint clue what the person in there is actually doing. Or if there isn't a channel for a third party to listen/read.
        Stop TCPA, stupid software patents and corrupt politicians!

        Comment


        • #5
          Originally posted by Adarion View Post
          Green Sardine? Red Herring?
          Either way, while I like ASIC-style stuff for offloading certain specific tasks (very fast execution at low power consumption, CPU cycles saved) I am still reluctant when it comes to black boxes. Especially for sensitive stuff like cryptography.

          I mean, would you write a letter and then hand it to some obscure person sitting inside a letterbox to crypt it and then hand the crypted letter back out through the little opening? Sounds scary to me. And you don't even have a faint clue what the person in there is actually doing. Or if there isn't a channel for a third party to listen/read.
          This is why some OSes like OpenBSD refuse to use hardware accelerators but like you said it is a double edged sword because you suck in performance with the ambiguous benefit of maybe greater security IF there is a backdoor in the black box. I think OpenBSD uses AES functionality in CPUs though to accelerate decrypting on FDE drives, but I could be wrong.

          Comment


          • #6
            Originally posted by Adarion View Post
            Green Sardine? Red Herring?
            Either way, while I like ASIC-style stuff for offloading certain specific tasks (very fast execution at low power consumption, CPU cycles saved) I am still reluctant when it comes to black boxes. Especially for sensitive stuff like cryptography.

            I mean, would you write a letter and then hand it to some obscure person sitting inside a letterbox to crypt it and then hand the crypted letter back out through the little opening? Sounds scary to me. And you don't even have a faint clue what the person in there is actually doing. Or if there isn't a channel for a third party to listen/read.
            Does it really matter when Intel ME and (presumably) AMD PSP can read your plaintext directly from RAM anyway?

            Comment


            • #7
              That acronym is so unfortunate.

              Comment


              • #8
                Originally posted by microcode View Post
                That acronym is so unfortunate.
                CCCP and the red team?

                Comment


                • #9
                  Originally posted by kiffmet View Post
                  I am still waiting for being able to use the CCP in my 3900X w/ Aorus Pro X570 for offloading crypto algorithms. The CCP driver complains about my BIOS not properly setting up the device and it refuses to work. The device seems to be working just fine on Windows (which makes me think that the BIOS has nothing to do with it), hence suggesting that the Linux driver needs a few more touchups.
                  This. It happens on both my 2700U and my 3700X. HP and ASRock, couldn't be more different UEFI.

                  Comment


                  • #10
                    Originally posted by numacross View Post
                    Does it really matter when Intel ME and (presumably) AMD PSP can read your plaintext directly from RAM anyway?
                    I'd say so, because RAM is huge by comparison to the amount of data one is usually encrypting. Also, the packets being sent probably exist in RAM for only a short amount of time.

                    In this case, you can just listen in on specific conversations, and maybe even with enough context to tell them apart.

                    Comment

                    Working...
                    X