Announcement

Collapse
No announcement yet.

Linux 5.10 Hardens Against Possible DMA Attacks By External PCIe Devices

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

  • Linux 5.10 Hardens Against Possible DMA Attacks By External PCIe Devices

    Phoronix: Linux 5.10 Hardens Against Possible DMA Attacks By External PCIe Devices

    The PCI changes were submitted on Wednesday for the Linux 5.10 kernel...

    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
    One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

    This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.

    Comment


    • #3
      Originally posted by kobblestown View Post
      One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

      This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.
      There might be a reason they skipped it. This is probably used by a government to surveill citizens en-mass.
      AS you said, every NIC has microcontroller. And those are usually tied to particular computer, location and user.
      Once they have the green light, NIC is gewts "magic packet" that makes it go zombie and opens the machine.
      It's obvious, why would they want to keep this vector for themselves.

      But they can't have all those DIY enterpreneurs walk around with enrichened USB drives etc.

      Comment


      • #4
        It's because external implies a plug and play hack, internal implies a plug and play hack after you've opened up the system. One hack takes literal seconds and can be accomplished by anyone with decent social engineering skills, the other hack requires the person to open a computer. Most people will realize that the person disassembling their work PC isn't Jeff from IT.

        Comment


        • #5
          Originally posted by kobblestown View Post
          One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

          This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.
          If you can't trust the hardware inside your computer your data is already pwned.
          That said, it's indeed a sad state of computing that closed-source drivers and firmware are still a thing.

          Comment


          • #6
            Originally posted by jntesteves View Post

            If you can't trust the hardware inside your computer your data is already pwned.
            That said, it's indeed a sad state of computing that closed-source drivers and firmware are still a thing.
            That's not exactly true. Ensuring that, say, a network controller only accesses the network buffers - as opposed to the entire physical RAM - makes a lot of sense.

            Comment


            • #7
              Originally posted by yariv View Post

              That's not exactly true. Ensuring that, say, a network controller only accesses the network buffers - as opposed to the entire physical RAM - makes a lot of sense.
              I haven't ever looked at Kernel code so I have no idea how that works, but I never thought what you are describing was possible anyway. I thought a device could only access memory mapped and made available to it by it's in-kernel driver. If that driver is a blob, then yes that's true, but I didn't expect it otherwise.

              Comment


              • #8
                Originally posted by jntesteves View Post

                I haven't ever looked at Kernel code so I have no idea how that works, but I never thought what you are describing was possible anyway. I thought a device could only access memory mapped and made available to it by it's in-kernel driver. If that driver is a blob, then yes that's true, but I didn't expect it otherwise.
                Only if driver is written to use the IOMMU, which is a surprisingly recent addition to x86-family machines. Otherwise, the DMA-capable device has unrestricted access for backwards compatibility.

                Comment

                Working...
                X