Announcement

Collapse
No announcement yet.

AMD openSIL Detailed For Advancing Open-Source System Firmware

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

  • #21
    Originally posted by Developer12 View Post
    You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

    Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.
    What? I'm not talking about stopping the use of microcode, but opening it up. It's precisely because of things like PSP that I want to see every blobs opened and scrutinized. Proprietary shit and inherently untrustworthy, and the move towards more closed firmware for is basically "security through obscurity" in disguise. I don't think there's any need to elaborate on why that's stupid.

    As Ironmask​ says, closed microcode—no matter how "necessary" to function—are dubious at best; I want to see everything as open as POWER9.

    Comment


    • #22
      Cool. Now we have an open firmware for shit spying on users called Microsoft Pluton.

      Comment


      • #23
        Originally posted by stormcrow View Post
        The only positive is that the static libraries might be written in some language other than assembly or C although all they actually say is another vague "industry standard language", which can mean anything.
        Obviously this is an attempt to re-establish Lisp machine dominance.

        Comment


        • #24
          Originally posted by Developer12 View Post

          You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

          Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.

          The FSF's libre hardware aspirations are dead. RYF is itself has always been in complete contradiction with reality.
          Since 486. Since PP/P2 it is patchable, because of that notorious P1 bug.

          Comment


          • #25
            Originally posted by RejectModernity View Post
            Cool. Now we have an open firmware for shit spying on users called Microsoft Pluton.
            Not just spying, but CPU Level Enforcement of ALL? So far no public documentation that I've seen and my opinion is Microsoft Pluton should be (another) Red Line moment for Linux and FOSS. My only option is not buying the new cpu's with Pluton as I value self-custody of my own private keys.
            Last edited by RAINFIRE; 15 April 2023, 06:55 AM.

            Comment


            • #26
              Originally posted by Developer12 View Post

              You're crazy if you think CPUs will stop using microcode. Every CPU made since the 8086 contains it, and the preloaded microcode has only grown larger and larger

              Plus, there are far worse things than microcode on AMD platforms. All the ram init and other key stuff has been pushed down into the far more locked down Platform Security Processor firmware, making it worse than intel who at lest leave it up in the closed-source FSP binaries that you can load or (theoretically) replace yourself.

              The FSF's libre hardware aspirations are dead. RYF is itself has always been in complete contradiction with reality.
              Using microcode doesn't prevent you from releasing its source code: I'm writing this message from a Raptor CS Talos 2 with an IBM Power 9 which is free down to the firmware.
              Last edited by darkbasic; 15 April 2023, 06:56 AM.
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #27
                I wish AMD would actually release the code and not limit it to specific hardware. I don't want another rocm mess.

                It has been 6 years: https://www.reddit.com/r/Amd/comment...mment/def5h1b/

                Originally posted by Ironmask View Post

                I always found the politics behind microcode to be funny.

                >This is my CPU architecture. You can see the layout, but given that it's too complex to modify or make for yourself, there's no need to worry about licenses or anything.
                >Oh great, can't wait to use it.
                >And of course some of the logic was done in microcode instead of physical circuits to save on development costs.
                >NO NO NO I HAVE TO BE ABLE TO EDIT THAT PART THATS DIFFERENT
                The problem people have with this about device mutation/manipulation. Besides security issues I don't care that much for microcode. Firmware on the other hand...​

                Releasing a device that runs too hot or uses too much power then waiting for benchmarks and reviews to settle and changing the devices making it slower to avoid getting too many RMAs. There's also artificially limiting devices which gives people the hope of still being able to unlock the true power of their devices. Modding can be fun like when I started with changing a Radeon 980 se to 980 pro by modifying firmware. Later another big win was getting to boot from a PCIe NVMe drive on Intel Z77. It save me a ton of money not needing to upgrade my entire system. I helped a friend with the same problem on a Z87 platform too. Officially NVMe boot drive support from Intel came with Z97 but it was just Intel/vendors wanting to force people to upgrade when the hardware was more than capable. There's countless abuse examples without having to open the UEFI faulty-TPMs and secure-boot can of worms. https://www.youtube.com/watch?v=Dfl2JI2eLc8 People get butt hurt over this because they see what has happened in the past.

                Besides the security issues. I wonder what people would have been able to do if they had unrestricted access to their systems. Think about it compared to car modifications. Take a look at what AMG did and how that became a big win for Mercedes. Kingpin and EVGA was a big win too. https://www.youtube.com/watch?v=cr3lsU718Lg Now EVGA is no-more thanks to restrictions and abuse.

                PS: Even the raspberry pi suffers from open boot issues. As others have said in this thread, there are very few options for really open systems.

                Comment


                • #28
                  Originally posted by Jabberwocky View Post
                  The problem people have with this about device mutation/manipulation. Besides security issues I don't care that much for microcode. Firmware on the other hand...​
                  what makes you think microcode does not have back doors?

                  Comment


                  • #29
                    Originally posted by cj.wijtmans View Post

                    what makes you think microcode does not have back doors?
                    I'll rephrase: Besides the back doors and other security issues I don't care that much for microcode.

                    Comment

                    Working...
                    X