On Tue, 2013-09-03 at 19:50 -0400, Matthew Garrett 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 modify > kernel code, allowing them to circumvent disabled module loading or module > signing. Default to paranoid - in future we can potentially relax this for > sufficiently IOMMU-isolated devices. Can you elaborate on what you mean by "sufficiently IOMMU-isolated", and what's missing before we can do that? If a given device is protected by an active IOMMU, and if there's no driver loaded and hence no active DMA mappings for the device in question, then we ought to be able to prod at it safely, right? It can't DMA anywhere anyway. If there's a driver loaded but still no active DMA mappings, that's should still be OK, albeit harder to check. If there are active mappings, that's less clear... we can still only scribble on memory ranges which were already *mapped* for this device to write to (ring buffers, receive buffers, etc.). But it's still probably best not to allow it? And there are non-DMA considerations too, aren't there? What about just writing some fun stuff to a memory BAR and then writing to PCI config to map that BAR to an address that we can get executed by kernel code? -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
