From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1CBCC3524D for ; Mon, 3 Feb 2020 07:47:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4713420658 for ; Mon, 3 Feb 2020 07:47:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="tIPQmbMB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4713420658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8D43D6B0630; Mon, 3 Feb 2020 02:47:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 884C56B0631; Mon, 3 Feb 2020 02:47:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79A3C6B0632; Mon, 3 Feb 2020 02:47:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 604566B0630 for ; Mon, 3 Feb 2020 02:47:06 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0519E181AEF10 for ; Mon, 3 Feb 2020 07:47:06 +0000 (UTC) X-FDA: 76448034852.24.run77_39f98a580401 X-HE-Tag: run77_39f98a580401 X-Filterd-Recvd-Size: 5233 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Feb 2020 07:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1OnLUtccVxzRGy3H6tEuURVA5Cw1eDsrX9HvO+XJeD4=; b=tIPQmbMBJJkyM1EUffKpQ6t8+ 6fwTSe6r4ihL5NqNlss4BtnMRFyaJcEPiVZ64i/7LitZrfYs81oZ1L69NyPjMREv3zXAuPxvS0bI2 eMLUSHfCDe+Uhbh/03f2I/93N1FOLazKz82/5pZp0ZjY/ieytY6YhoUGFolkmaBRB9ehsBDiIZHK+ bkuV60ig9MmsNyEVGt8E0ZhQVk6ERJlJE/YSTpSCBFbCtPNtYKIiwbs9X9JfUX2DCkFMoZJyTbNcM L+Sm7T5i2/9zTP8/s+1LrDkKFqoSf7iPfX+6fv7NwwWoLbf8UowsIMPpObCqY5IZs9aWtvn+JjE0x uAmUP6+mA==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iyWRQ-0001Y1-VE; Mon, 03 Feb 2020 07:46:44 +0000 Date: Sun, 2 Feb 2020 23:46:44 -0800 From: Matthew Wilcox 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 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: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.