Re: [PATCH V3 02/11] PCI: Lock down BAR access when module security is enabled

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

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@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]