Announcement

Collapse
No announcement yet.

Coreboot's Flashrom Working On Radeon GPU Flashing Support

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

  • #21
    Originally posted by faph View Post
    It does help in the sense that you can at least trust the firmware then...
    It does not help with anything modern that enforces crypto signatures (like Vega cards, or NVIDIA's stuff), and as such it is a dead end not worth pursuing.
    Last edited by starshipeleven; 19 October 2018, 03:57 PM.

    Comment


    • #22
      Originally posted by WorBlux View Post
      Or even just a physical jumper or switch on the card to override the check would suffice.
      the crypto signature checking is there to protect the card's secrets or to ensure that the card is "secure" for third parties that want to use its features.

      A jumper would defy the point.

      Comment


      • #23
        Originally posted by libv View Post
        So you are saying that VEGA can no longer be initialized by simply running atomBIOSes ASICInit() function?
        No he is not.

        Ever heard about signed firmware? By now you should.

        Comment


        • #24
          Originally posted by faph View Post
          It does help in the sense that you can at least trust the firmware then...
          but how does it help you to trust hardware? he said "trust hardware", not "at least trust firmware"
          Originally posted by faph View Post
          Anyways the work is about to make it possible to flash an ATI/AMD firmware under linux at all! (besides the obscure atiflash binary)

          Which is definitely worth supporting. I hope some miners catch interest and support him.
          under linux you can just tweak driver, it is already open

          Comment


          • #25
            Originally posted by starshipeleven View Post
            the crypto signature checking is there to protect the card's secrets or to ensure that the card is "secure" for third parties that want to use its features.

            A jumper would defy the point.
            Not really. Everyone working on the card knows the secrets and it's cheaper to snipe talent than reverse engineer. For the second count it's almost as stupid as hdcp strippers are out there, but even if idiots insist you can implements a two stage loader or other scheme that will blow a usable link query-able from user-space when a unsigned image-has ever been loaded

            Comment


            • #26
              Originally posted by WorBlux View Post
              Everyone working on the card knows the secrets and it's cheaper to snipe talent than reverse engineer.
              Does not matter what you think but what the management thinks. They think their IP is precious and that this is a good way to protect it. This is what happens when people deciding of technology don't know shit about it.

              For the second count it's almost as stupid as hdcp strippers are out there,
              Same as above. HDCP has never really been an effective antipiracy measure, it was never even designed to be half-safe until very recent times (when it is at least trying to, not that hard of course), but allows everyone to say they have DRM so the media providers are happy.

              Having a "trusted" environment to execute your payload is a thing, and it does not matter if 99% of the times whatever userspace application actually using these hardware features is a complete piece of shit that stores keys unencrypted in the same ram space in its stack or something similarly stupid so the actual hardware protections are never ever even considered in a successful hacking.

              but even if idiots insist you can implements a two stage loader or other scheme that will blow a usable link query-able from user-space when a unsigned image-has ever been loaded
              This would basically "taint" hardware and would expose them to a lot of potential PR damage if bugs or even malicious attacks are deployed to affect systems on a large scale so that their DRM capabilities are disabled en-masse

              (again I presonally doubt this is even going to happen but think of the management)
              Last edited by starshipeleven; 01 January 2019, 04:45 PM.

              Comment


              • #27
                Is Luc still working on this? Has anyone successfully flashed a modern AMD GPU with open source firmware?

                Comment


                • #28
                  Originally posted by make_adobe_on_Linux! View Post
                  Is Luc still working on this? Has anyone successfully flashed a modern AMD GPU with open source firmware?
                  Once could argue that the current vbios (at least the data and command tables) are open. The data and command tables are fully documented in the open source Linux kernel driver. The GOP and VBE modules are still closed source, but if you don't need a pre-OS environment, the open source Linux GPU driver can fully initialize the GPU using just the data and command tables in conjunction with the logic in the driver.

                  Comment


                  • #29
                    Originally posted by agd5f View Post

                    Once could argue that the current vbios (at least the data and command tables) are open. The data and command tables are fully documented in the open source Linux kernel driver. The GOP and VBE modules are still closed source, but if you don't need a pre-OS environment, the open source Linux GPU driver can fully initialize the GPU using just the data and command tables in conjunction with the logic in the driver.
                    But why was it so hard for Luc to achieve flashing any AMD cards with new firmware that works, then? You make it sound like that could be done today... If I'm misunderstanding, then would you mind going into more detail about how it would be done? I think even raptorcs systems - which are the closest we have to de-blobbed - have removed the AMD firmware blobs.

                    Comment


                    • #30
                      Originally posted by make_adobe_on_Linux! View Post

                      But why was it so hard for Luc to achieve flashing any AMD cards with new firmware that works, then? You make it sound like that could be done today... If I'm misunderstanding, then would you mind going into more detail about how it would be done? I think even raptorcs systems - which are the closest we have to de-blobbed - have removed the AMD firmware blobs.
                      The vbios is really only needed to handle the pre-OS console and for board specific configuration data. If you don't need a console until the OS loads, then you are pretty much there already today. The data in the vbios data tables are generally board specific, so there no real need to change it and all of the structures are defined, so you know exactly what data is stored there and how it's used. For the command tables, they are interpreted byte code. The driver has an interpreter so you can see exactly what the programming sequences in the command tables are doing. There are also tools like atomdis (https://cgit.freedesktop.org/~mhopf/AtomDis/) if you want to see what the command or data tables contain. Many of these command tables are also board specific as the programming sequences are dependent on the board design. So no real need to change any of that either. If you need a pre-OS console environment and don't want to use the GOP or VBE interfaces, our your platform doesn't support those interfaces, you can either write a small driver based on the Linux GPU driver code which does enough init to light up the displays, or just use the Linux GPU driver directly if you are doing something like coreboot. The GOP and VBE code do pretty much the same thing that the driver does; parse the data tables to get the board configuration and execute the command table to initialize the board.
                      Last edited by agd5f; 07 January 2022, 02:34 PM.

                      Comment

                      Working...
                      X