Announcement

Collapse
No announcement yet.

AMDGPU Firmware Blobs Updated For Video Encode/Decode

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

  • #71
    Originally posted by coder View Post
    it's only at their own discretion that they use an IOMMU
    lol, what the purpose of iommu then? in reality discretion comes from operating system

    Comment


    • #72
      Originally posted by pal666 View Post
      only for idiots
      hardware is also bits of ones and zeroes. so it does not matter where those bits were burned in silicon, executed from rom, or executed from other memory. we have two levels of idiocy here. fsf's level is "you can burn in silicon or execute from rom, but not from other memory". your level is "you can only burn into silicon". i think your variant is more idiotic than fsf's one
      good luck running those shaders at all without hardware, moron. see, there is no difference
      i am saying that it should be opensourced, but its opensourceness should be benchmarked against other hardware. so for now it is just as closed as other closed hardware

      denying that firmware is hardware implementation detail is just idiocy
      And by your logic that means they can implement whatever they want in firmware and call it hardware.... That's true idiocy.

      Comment


      • #73
        Originally posted by pal666 View Post
        lol, what the purpose of iommu then? in reality discretion comes from operating system
        PCIe uses physical addresses. The GPU can conceivably just ignore its MMU and read or write wherever it wants. To the extent that its MMU is controlled by the GPU's firmware (I'm betting at least its configuration is), then you're trusting firmware that you cannot inspect. I guess you're going to answer that it's no different than trusting hardware you of which you can't inspect the design, but the firmware is something that could conceivably be patched (or even hacked, if the keys are leaked), should there be a bug or security hole.

        I'm not trying to take a hard position on the matter - just exploring some of the potential arguments. Ultimately, I'd say the design flaw is in PCIe, for its use of physical addresses. Changing that would solve numerous device/firmware trust issues, including Thunderbolt vulnerabilities.

        Comment


        • #74
          Originally posted by pal666 View Post
          wrong. there is processor executing instructions in each keyboard, mouse, hdd or monitor. and nobody treat them as software because from host operating system pov they are hardware black boxes
          You can treat some of these parts as black boxes like SATA HDDs (just write bytes and read bytes). However, if your HDD is connected through Thunderbolt then you can definitely not treat it as a black box. BadUSB has shown that benign looking USB devices can be problematic. Historically, even the i8042 keyboard controller in the IBM PC/AT had some special functions like controlling the 21st bit on the address bus.

          And graphics cards cannot be treated as black box. Not only are they DMA capable (and their DMA engine running some proprietary firmware that gets loaded into it every boot), but thanks to GPGPU an increasing amount software on your computer will execute on the GPU, under the supervision of the proprietary firmware that you load into it.

          Originally posted by bridgman View Post
          Not exactly... the FSF recommendations cover hardware that ships without dynamically loadable proprietary microcode. The amusing thing is that as a consequence they end up recommending some of the most heavily microcoded hardware available - the microcode is just executed from ROM rather than from RAM.
          I'm pretty sure that is not where the distinction lies according to the FSF. With reprogrammable instructions it remains important whether these get updated in practice or not. If they are typically unchanged for the lifetime of the device, then they can be considered hardware.

          Originally posted by coder View Post
          I'll probably regret adding fuel to the fire, but it's maybe worth considering that GPUs can read & write all host memory (if I'm not mistaken, it's only at their own discretion that they use an IOMMU - and we simply trust them to implement this correctly and never go around it).
          Originally posted by pal666 View Post
          lol, what the purpose of iommu then? in reality discretion comes from operating system
          IOMMUs have a very bad track record protecting against DMA based attacks, which ironically is the very thing they are designed for. They work properly only if the stars align right, and especially not during early boot (which has been exploited e.g. with PCILeech). I have ranted against relying on IOMMUs many times on this forum.
          Last edited by chithanh; 01-27-2018, 07:45 PM.

          Comment


          • #75
            Originally posted by chithanh View Post
            I'm pretty sure that is not where the distinction lies according to the FSF. With reprogrammable instructions it remains important whether these get updated in practice or not. If they are typically unchanged for the lifetime of the device, then they can be considered hardware.
            Agreed, and they also have an "in practice" distinction between dynamically loaded images stored in flash vs images shipped as files with the driver (as well as some distinction based on whether BIOS or driver code does the loading), but since you can't tell if images are going to be updated during the lifetime of the device until the device's life has ended all dynamically loadable images tend to get the same hairy eyeball.

            Comment

            Working...
            X