On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett <matthew.garrett@xxxxxxxxxx> wrote: > Any hardware that can potentially generate DMA has to be locked down from > userspace in order to avoid it being possible for an attacker to cause > arbitrary kernel behaviour. Default to paranoid - in future we can > potentially relax this for sufficiently IOMMU-isolated devices. > > Signed-off-by: Matthew Garrett <matthew.garrett@xxxxxxxxxx> As noted here: https://bugzilla.redhat.com/show_bug.cgi?id=908888 this breaks pci passthru with QEMU. The suggestion in the bug is to move the check from read/write to open, but sysfs makes that somewhat difficult. The open code is part of the core sysfs functionality shared with the majority of sysfs files, so adding a check there would restrict things that clearly don't need to be restricted. Kyle had the idea to add a cap field to the attribute structure, and do a capable check if that is set. That would allow for a more generic usage of capabilities in sysfs code, at the cost of slightly increasing the structure size and open path. That seems somewhat promising if we stick with capabilities. I would love to just squarely blame capabilities for causing this, but we can't just replace it with an efi_enabled(EFI_SECURE_BOOT) check because of the sysfs open case. I'm not sure there are great answers here. josh -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
