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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Sep 2013 17:57:41 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	keescook@...omium.org, hpa@...or.com
Subject: Re: [PATCH V3 02/11] PCI: Lock down BAR access when module security
 is enabled

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

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)