Announcement

Collapse
No announcement yet.

Firewire IEEE-1394 Support Continues To Be Improved With The Linux 6.10 Kernel

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

  • Firewire IEEE-1394 Support Continues To Be Improved With The Linux 6.10 Kernel

    Phoronix: Firewire IEEE-1394 Support Continues To Be Improved With The Linux 6.10 Kernel

    While most of you have not thought about or used Firewire (IEEE-1394) in years, there still are some legacy digital video cameras and some professional audio devices relying on the interface. Last year saw a new Firewire maintainer step-up for the Linux kernel after the code had fallen dormant. The plans by that new maintainer, Takashi Sakamoto, are to maintain Linux's Firewire support through 2029. He's continuing to do a good job with the upcoming Linux 6.10 kernel bringing the latest batch of Firewire enhancements...

    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
    Firewire was so much better than USB: https://www.youtube.com/watch?v=IXBC85SGC0Q

    Comment


    • #3
      Originally posted by rene View Post
      Firewire was so much better than USB: https://www.youtube.com/watch?v=IXBC85SGC0Q
      It still is, in everything but speed. You know what you are getting with it, and the naming, while insane for the time, is tame compared to USB C 3.2 2x2 with Thunderbolt.

      If firewire had survived, it would have been a simple speed bump past the 1.2 Gbp/s of the final spec, and since they liked changing the pinout each version anyway, you would know what yours supported. If they added Thunder bolt, they would have just bumped the version, and mandated it as part of the standard with that connector.

      Comment


      • #4
        Originally posted by dragorth View Post

        It still is, in everything but speed. You know what you are getting with it, and the naming, while insane for the time, is tame compared to USB C 3.2 2x2 with Thunderbolt.

        If firewire had survived, it would have been a simple speed bump past the 1.2 Gbp/s of the final spec, and since they liked changing the pinout each version anyway, you would know what yours supported. If they added Thunder bolt, they would have just bumped the version, and mandated it as part of the standard with that connector.
        Being able to plug a firewire cable into 2 computers and have an instant network between them was also pretty cool but obviously a bit of a niche use case.

        Comment


        • #5
          The same thing that gave FireWire its performance was also what made it insecure, though: it allowed connected devices direct access to the host system RAM through DMA.

          This allowed for DMA attacks: simply by plugging a malicious device into the FireWire port of a host system, ons could access its internal memory. At least Thunderbolt can be secured by having the user first consent to a plugged-in device being initialized and used. I'm not sure if FireWire could be secured through software in a similar way. Perhaps the presence of an IOMMU in newer systems would allow FireWire controllers only access to a specific sandboxed memory region?

          Comment


          • #6
            Originally posted by SteamPunker View Post
            The same thing that gave FireWire its performance was also what made it insecure, though: it allowed connected devices direct access to the host system RAM through DMA.

            This allowed for DMA attacks: simply by plugging a malicious device into the FireWire port of a host system, ons could access its internal memory. At least Thunderbolt can be secured by having the user first consent to a plugged-in device being initialized and used. I'm not sure if FireWire could be secured through software in a similar way. Perhaps the presence of an IOMMU in newer systems would allow FireWire controllers only access to a specific sandboxed memory region?
            That is a software problem, mostly. The OS could just give that consent blindly, which is essentially all it does with firewire, by design. You just design it to have the option, and create a secure area of memory for backwards compatible devices. Most of them weren't made for 64bit addressed systems anyway, so you aren't even keeping a large amount of memory free, 2GB at most and only when a device is plugged in.

            Or, you can just have the OS talk to the device, and then not actually do any of the things it asks until the user gives the OK.

            Comment

            Working...
            X