From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches Date: Sun, 2 Feb 2020 23:46:44 -0800 Message-ID: <20200203074644.GD8731@bombadil.infradead.org> References: <5861936c-1fe1-4c44-d012-26efa0c8b6e7@de.ibm.com> <202001281457.FA11CC313A@keescook> <6844ea47-8e0e-4fb7-d86f-68046995a749@de.ibm.com> <20200129170939.GA4277@infradead.org> <771c5511-c5ab-3dd1-d938-5dbc40396daa@de.ibm.com> <202001300945.7D465B5F5@keescook> <202002010952.ACDA7A81@keescook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Jann Horn Cc: Kees Cook , Christian Borntraeger , Christoph Hellwig , Christopher Lameter , Jiri Slaby , Julian Wiedmann , Ursula Braun , Alexander Viro , kernel list , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , linux-xfs@vger.kernel.org, Linus Torvalds , Andy Lutomirski , "David S. Miller" , Laura Abbott List-Id: linux-arch.vger.kernel.org On Sat, Feb 01, 2020 at 08:27:49PM +0100, Jann Horn wrote: > FWIW, as far as I understand, usercopy doesn't actually have any > effect on drivers that use the modern, proper APIs, since those don't > use the slab allocator at all - as I pointed out in my last mail, the > dma-kmalloc* slabs are used very rarely. (Which is good, because > putting objects from less-than-page-size slabs into iommu entries is a > terrible idea from a security and reliability perspective because it > gives the hardware access to completely unrelated memory.) Instead, > they get pages from the page allocator, and these pages may e.g. be > allocated from the DMA, DMA32 or NORMAL zones depending on the > restrictions imposed by hardware. So I think the usercopy restriction > only affects a few oddball drivers (like this s390 stuff), which is > why you're not seeing more bug reports caused by this. Getting pages from the page allocator is true for dma_alloc_coherent() and friends. But it's not true for streaming DMA mappings (dma_map_*) for which the memory usually comes from kmalloc(). If this is something we want to fix (and I have an awful feeling we're going to regret it if we say "no, we trust the hardware"), we're going to have to come up with a new memory allocation API for these cases. Or bounce bugger the memory for devices we don't trust. The problem with the dma_map_* API is that memory might end up being allocated once and then used multiple times by different drivers. eg if I allocate an NFS packet, it might get sent first to eth0, then (when the route fails) sent to eth1. Similarly in storage, a RAID-5 driver might map the same memory several times to send to different disk controllers. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:58872 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727652AbgBCHqw (ORCPT ); Mon, 3 Feb 2020 02:46:52 -0500 Date: Sun, 2 Feb 2020 23:46:44 -0800 From: Matthew Wilcox Subject: Re: [kernel-hardening] [PATCH 09/38] usercopy: Mark kmalloc caches as usercopy caches Message-ID: <20200203074644.GD8731@bombadil.infradead.org> References: <5861936c-1fe1-4c44-d012-26efa0c8b6e7@de.ibm.com> <202001281457.FA11CC313A@keescook> <6844ea47-8e0e-4fb7-d86f-68046995a749@de.ibm.com> <20200129170939.GA4277@infradead.org> <771c5511-c5ab-3dd1-d938-5dbc40396daa@de.ibm.com> <202001300945.7D465B5F5@keescook> <202002010952.ACDA7A81@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Jann Horn Cc: Kees Cook , Christian Borntraeger , Christoph Hellwig , Christopher Lameter , Jiri Slaby , Julian Wiedmann , Ursula Braun , Alexander Viro , kernel list , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM , linux-xfs@vger.kernel.org, Linus Torvalds , Andy Lutomirski , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Dave Kleikamp , Jan Kara , Marc Zyngier , Matthew Garrett , linux-fsdevel , linux-arch , Network Development , Kernel Hardening , Vlastimil Babka , Michal Kubecek Message-ID: <20200203074644.HbChpfEU-xBRz16CKUXOgzKV5E7oYJm6VukOPkttGGk@z> On Sat, Feb 01, 2020 at 08:27:49PM +0100, Jann Horn wrote: > FWIW, as far as I understand, usercopy doesn't actually have any > effect on drivers that use the modern, proper APIs, since those don't > use the slab allocator at all - as I pointed out in my last mail, the > dma-kmalloc* slabs are used very rarely. (Which is good, because > putting objects from less-than-page-size slabs into iommu entries is a > terrible idea from a security and reliability perspective because it > gives the hardware access to completely unrelated memory.) Instead, > they get pages from the page allocator, and these pages may e.g. be > allocated from the DMA, DMA32 or NORMAL zones depending on the > restrictions imposed by hardware. So I think the usercopy restriction > only affects a few oddball drivers (like this s390 stuff), which is > why you're not seeing more bug reports caused by this. Getting pages from the page allocator is true for dma_alloc_coherent() and friends. But it's not true for streaming DMA mappings (dma_map_*) for which the memory usually comes from kmalloc(). If this is something we want to fix (and I have an awful feeling we're going to regret it if we say "no, we trust the hardware"), we're going to have to come up with a new memory allocation API for these cases. Or bounce bugger the memory for devices we don't trust. The problem with the dma_map_* API is that memory might end up being allocated once and then used multiple times by different drivers. eg if I allocate an NFS packet, it might get sent first to eth0, then (when the route fails) sent to eth1. Similarly in storage, a RAID-5 driver might map the same memory several times to send to different disk controllers.