Announcement

Collapse
No announcement yet.

AMD Dynamic Boost Control Submitted For Linux 6.6

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

  • AMD Dynamic Boost Control Submitted For Linux 6.6

    Phoronix: AMD Dynamic Boost Control Submitted For Linux 6.6

    Back in April AMD Linux engineers posted enabling a new CPU feature called Dynamic Boost Control to be found with some unspecified Ryzen SoCs for tuning the processor cores for optimal performance. The Dynamic Boost Control functionality depends upon the AMD Cryptographic Co-Processor (CCP) / Platform Security Processor (PSP) and this functionality was submitted today as part of the crypto updates for Linux 6.6...

    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
    It's extremely stupid the requirement of a black box in the CPU/SoC, but even worse to require it for controlling that stuff.

    I really hope RISC-V becomes more widespread and able to compete in raw computing power against more powerful high end CPU/SoCs these days, but with really open design and a lot cheaper and even more advanced semiconductor manufacturing methods.

    Comment


    • #3
      This whole thing is very opaque.

      First of all, what parameters exactly is this used to control that are not already available thru other channels?
      And far more importantly, why in the name of fuck is this being built into the PSP and commands have to be digitally signed? Can anyone come up with any remotely reasonable explanation? This is fishy at best, and certainly nothing good for the user will come out of this.

      I have some theories:
      - Combining this with trusted computing initiatives so performance is locked if running non-sanctioned software
      - Restrict control around power/perf parameters to limit user tinkering and force consumers to buy specific SKUs
      - Infrastructure to implement something similar to "intel on demand". Pay recurring license to use the hardware you already bought
      - Another attack vector for government agencies (not that they need it). Widely available, very opaque and digitally signed with a built-in key, I'd be salivating if I were the NSA

      Comment


      • #4
        another argument coulf be that controlling frequency and power from a separate coprocessor is more practical as it could all be in one place and main processor cores do not have to be active to be controlled. I am no hardware architect but there is no need to assume mallice.

        Comment


        • #5
          Originally posted by qlum View Post
          another argument coulf be that controlling frequency and power from a separate coprocessor is more practical as it could all be in one place and main processor cores do not have to be active to be controlled. I am no hardware architect but there is no need to assume mallice.
          Even if you believe there is an "architectural advantage" to this, which I doubt, the "no malice" part of the argument fails because of the crypto signatures part of it.

          The only reason to build this crypto is if you plan to use it. Given that what they restrict are root-only kernel interfaces, the only reason to build it is to restrict end-users.
          My bet is a future "AMD On-Demand" is the main motivator, but once the infrastructure is in place it will of course be used for other purposes as well.

          Comment


          • #6
            Funny how the same hostility displayed here for AMD its never replicated with intel and Ngreedia, which are between bad (intel) to way worse than AMD (Ngreedia).

            Comment


            • #7
              Sounds like DRM to me.
              "Sorry bud, but you need an active subscription to unlock the boost"

              To hell with these blackboxes. Can't wait for RISC-V to become powerful enough for my regular use cases...

              Comment


              • #8
                Originally posted by NeoMorpheus View Post
                Funny how the same hostility displayed here for AMD its never replicated with intel and Ngreedia, which are between bad (intel) to way worse than AMD (Ngreedia).
                Hahahahahaha wow. There are FIVE comments in this thread. Every thread with the word nvidia in it is at least 50 comments long and full of anti nvidia hate.

                Of course you already know this, because you post the same cringy comments in every single one

                Comment


                • #9
                  Originally posted by partcyborg View Post

                  Hahahahahaha wow. There are FIVE comments in this thread. Every thread with the word nvidia in it is at least 50 comments long and full of anti nvidia hate.

                  Of course you already know this, because you post the same cringy comments in every single one
                  White knight reporting :-)

                  Comment


                  • #10
                    Originally posted by dp_alvarez View Post
                    And far more importantly, why in the name of fuck is this being built into the PSP and commands have to be digitally signed? Can anyone come up with any remotely reasonable explanation?
                    The overclocking/undervolting interface can be used to mount voltage fault injection attacks.

                    Trusted Platform Modules constitute an integral building block of modern security features. Moreover, as Windows 11 made a TPM 2.0 mandatory, they are subject to an ever-increasing academic challenge. While discrete TPMs - as found in higher-end systems - have been susceptible to attacks on their exposed communication interface, more common firmware TPMs (fTPMs) are immune to this attack vector as they do not communicate with the CPU via an exposed bus. In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor, which constitutes the TEE for AMD's fTPMs. In contrast to previous dTPM sniffing attacks, this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection. First, we demonstrate the impact of our findings by - to the best of our knowledge - enabling the first attack against Full Disk Encryption solutions backed by an fTPM. Furthermore, we lay out how any application relying solely on the security properties of the TPM - like Bitlocker's TPM- only protector - can be defeated by an attacker with 2-3 hours of physical access to the target device. Lastly, we analyze the impact of our attack on FDE solutions protected by a TPM and PIN strategy. While a naive implementation also leaves the disk completely unprotected, we find that BitLocker's FDE implementation withholds some protection depending on the complexity of the used PIN. Our results show that when an fTPM's internal state is compromised, a TPM and PIN strategy for FDE is less secure than TPM-less protection with a reasonable passphrase.




                    A nefarious explanation might be that they want to sell overclockable high-core-count server parts at sky-high off-list prices to HFT traders and the like, but that's probably not a big enough market to explain it.

                    Comment

                    Working...
                    X