| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 08 Apr 2014 12:34:37 -0400 From: Mark Lord <mlord@...ox.com> To: linux-kernel@...r.kernel.org, yinghai@...nel.org, tytso@....edu Subject: driver skip pci_set_master, fix it? No. I am working a couple of drivers for chips that perform extensive bus-mastering ops. These including full SRIOV support, and allow assigning virtual functions to virtual machines, etc. One thing the driver (still in development) does for safety, is defer the call to pci_set_master() until *after* it has mapped the MMIO space of the chips, so it can reset/flush the DMA engines before giving them permission to scribble over host RAM. But a recent patch to the kernel has removed this from the driver's control. The core PCI now does pci_set_master() immediately on pci_enable_device(). This could be catastrophic in some situations, depending upon the state of the DMA engines in the device. If they have "leftovers" from a previous "life" (or a previous VM assignment), then they'll immediately resume accessing host RAM as soon as the driver calls pci_enable_device(), courtesy of the embedded call to pci_set_master(). This isn't good, and these may not be the only devices affected in this way. Can we perhaps not do that, or provide some other way to return control of bus-mastering to the device driver ? -- mlord@...ox.com Mark Lord -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists