Messages in this thread | | | Date | Wed, 27 Mar 2013 11:03:26 -0400 | Subject | Re: [PATCH 05/12] PCI: Require CAP_COMPROMISE_KERNEL for PCI BAR access | From | Josh Boyer <> |
| |
On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett <matthew.garrett@nebula.com> 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@nebula.com>
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
| |