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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AD1ED60D14 for ; Wed, 20 Nov 2024 09:29:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B8616B007B; Wed, 20 Nov 2024 04:29:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 767F36B0083; Wed, 20 Nov 2024 04:29:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62F426B0085; Wed, 20 Nov 2024 04:29:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3B1866B007B for ; Wed, 20 Nov 2024 04:29:26 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B0412405A6 for ; Wed, 20 Nov 2024 09:29:25 +0000 (UTC) X-FDA: 82805949744.02.B4E4177 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf15.hostedemail.com (Postfix) with ESMTP id C88F9A0004 for ; Wed, 20 Nov 2024 09:28:29 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=yjgCcvIT; dmarc=none; spf=none (imf15.hostedemail.com: domain of BATV+cbb21d110c0520ad0ba8+7759+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+cbb21d110c0520ad0ba8+7759+infradead.org+hch@bombadil.srs.infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732094872; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oTxAXTjVXZoLAW+Bx5Y5Ep3Bki0sGsRetJ0FYriKt9E=; b=38I3kXkFmxZwaOpTSVRF5eXx/zOwzeZPZyEq+BjF/JQ8CaBhudhAIqeTVGkiBuYcD224wa TEkpQ7/1r4ujeXR5zGZBdZdPa/+3NBrMdeu+l3VlHOlKl4RJQA8vd6a0tH6z76dlAheDNA p/IpscANi9eXFxxyEa66ek3nLjkyE/Y= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=yjgCcvIT; dmarc=none; spf=none (imf15.hostedemail.com: domain of BATV+cbb21d110c0520ad0ba8+7759+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+cbb21d110c0520ad0ba8+7759+infradead.org+hch@bombadil.srs.infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732094872; a=rsa-sha256; cv=none; b=as1HSj6m5IakbXtZTWSpPMycSNM+KbjPYIUn5Bco4+ZtnbZrLTBFsW8sod8zg5foTJF4Zz 9Rl/CRjIqbDMZWlLmWUPbZJAX8d3HCWXSVJUG0LyENn6CYIMuLRnsQheWNxOZ0gbf3854I WkOvZHyjlrkzEhSU6Nl28UJm2D/POLQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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; bh=oTxAXTjVXZoLAW+Bx5Y5Ep3Bki0sGsRetJ0FYriKt9E=; b=yjgCcvITm2AickyXzj/ru/pPI/ 9OvpSensAtN3aH6tX+JGZHaV/4DTR1IjP4OLS57yU9cayGfvExeOooPI6OSp9uIhhyvaPXUJL7368 DGWBozdkMVUQ6mnUz2gnkeRO7c0vEHcF2YC6u3NuKrfCoKEfDchdIHJqmAsMRbWZNyKkvBupIZ9Yj 3p0go4F9khZHlp8nd4yamaw9FmnTQMzcsdDuMQnRNh0y7VN6M7kfbsVQXg/XGSRyVZNj/Th0ZA7Oy jBrA47LCS4lSEIKk8GqEpFVKToY+jQ5k+ZtDSyaMSgivxMv4eodrAlyK/TMIUyvRXFCotm/IyJOFI 3HMbdplw==; Received: from hch by bombadil.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tDh1T-0000000EvDA-2ZuO; Wed, 20 Nov 2024 09:29:19 +0000 Date: Wed, 20 Nov 2024 01:29:19 -0800 From: Christoph Hellwig To: Brian Johannesmeyer Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Raphael Isemann , Cristiano Giuffrida , Herbert Bos , Greg KH , Keith Busch Subject: Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption Message-ID: References: <20241119205529.3871048-1-bjohannesmeyer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241119205529.3871048-1-bjohannesmeyer@gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C88F9A0004 X-Stat-Signature: sbg1y9i1dfasxo8fsq78oh8y848pk6kd X-HE-Tag: 1732094909-590178 X-HE-Meta: U2FsdGVkX1+Swn+0iy/Dy03o8ZgV2ZEL+S+ucI7hNF66YHrimvtz72WStN1ybnkwvAUgOEtbpIL/hM9iQJvQrv6vWZwB93uLJ/7wO+URliJGOOHfYKg2Ul01u5TXb6Z2fRk9EyjQIbsNwgezP74qoM5EBH7buyHurtxzBQeof/PPAgzH7LzVlNGExpUu3pzaljZnCeq4NMdUODIU/X354Ky7U6yV0+ZZ9N1fCUNBRengTFaSoS70f5keR1EDYn6vgkHus0SfenrRKW9QhQXSUA5arqtIuOQBXR/M1iJph7rLQOZMCzxOGRRwWTmeQp3GieciweGXFW39FTI0ZpjNpqjWfI0rXCywjdytA5LVFjCjH1j7IndG2rIfRovHhF8x+aeEtAdNtse+TvyV8jHtq1qTQdgQlc2zVWJaNzmDWM8Nhvolh8OI3FxnhQqgk5PZulm1fSQaJLOtQP6+arKknzW9h6AP3WDZ8QWV8zRYZu1IAnffPK2ZokXU78Mt0RHuQkv4H7ugbjoNNT4NkEqYT+1IjQUdrQlhTWo2HIUwMqivvNd+ytiJRM+MhhfU3nnlEhvWSvcWPAMuB9RQAdSZ2CQYOjFB/DXOOaVjOSztaoaJuXvrEnPL6m4IhDhbyf1HKE/HvqPHEofyAGABHV6w6SoWLZHOlT34MkiDvGAdjV1LaZlxr+Q3KzL6XQ7T32ijJAbxQgRREzCFNgmgXADrN+SCYEfQgm1mTrPhJi4s92myqUB5RSNCCq7Z/DSipH8zH55TblsUfBMtU02tW6wtN4QcoKk+tvfwS3smBrSKabInNlu3WUA93YeM4d8Nui8k9DpQGayJON18PQ2zsf324fxZ6n++QKjwkFWEFFV81KvYLoxiptm5gBZ0Q8OWCNDqIea45cl7kbEr7kaNqre1Be0lBhhctpUXwpe1aRrteWFuWR3Z3XBn9T+WD3Z2epOmfLffKuWtQWhmT0Ah1I2 /TqBWdG6 ZRSGUcwuoAd7XRauO/gauOtF+Gnk24nKtnBbVC2+UzDAUyuJ+p7NfOX4ZOLxUBKZ0YHkKpMDtmtu9xri9hQLLZc9108zlzDLF2c9gw0FD7p8J7kkO2Y/QEo/ZXYeKKRGOW5laPNAaMOgzmUx7NWfviIvJfSx3anqxKiRuJy59LMmMWlN1d5BbL54oC8LnZsT+k41e/SHvBtMlaMmM13clnSwZgZ4M5+lntrVSt7jz8PeKChIAl3fS625NGsY5pCl1Em4imsFAp/03QLfXUWifr14ChbAsW4valSC+6nKmgqeqmK7DFZc7Tqml+d4Gut1XaUqUHZPkHnHgZfIdBTxDxoUpw0nvqAMFycWKLabhK2D8F3KwtnBHBYcyUmkpAypAuOcgJQqCE9lHhvLOA1EW+4DHkujkVrhALeqCEdufUh3hw2+jvi5tKfKt2Ny1QvHIgBCsJeE+CgelSeOm8k/TSKAy8vMgda7Mb9rH4cEp4om3Hv2LrNVbBLBaX8lN7Hq5xQAIOxGmIRqm9LHSsLmYhmioAshw/QJ9zM6x 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: List-Subscribe: List-Unsubscribe: On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote: > We discovered a security-related issue in the DMA pool allocator. > > V1 of our RFC was submitted to the Linux kernel security team. They > recommended submitting it to the relevant subsystem maintainers and the > hardening mailing list instead, as they did not consider this an explicit > security issue. Their rationale was that Linux implicitly assumes hardware > can be trusted. You should probably Cc Keith as the person who most recently did major work on the dmpool code and might still remember how it works. > > **Threat Model**: While Linux drivers typically trust their hardware, there > may be specific drivers that do not operate under this assumption. Hence, > this threat model assumes a malicious peripheral device capable of > corrupting DMA data to exploit the kernel. In this scenario, the device > manipulates kernel-initialized data (similar to the attack described in the > Thunderclap paper [0]) to achieve arbitrary kernel memory corruption. > > **DMA pool background**. A DMA pool aims to reduce the overhead of DMA > allocations by creating a large DMA buffer --- the "pool" --- from which > smaller buffers are allocated as needed. Fundamentally, a DMA pool > functions like a heap: it is a structure composed of linked memory > "blocks", which, in this context, are DMA buffers. When a driver employs a > DMA pool, it grants the device access not only to these blocks but also to > the pointers linking them. > > **Vulnerability**. Similar to traditional heap corruption vulnerabilities > --- where a malicious program corrupts heap metadata to e.g., hijack > control flow --- a malicious device may corrupt DMA pool metadata. This > corruption can trivially lead to arbitrary kernel memory corruption from > any driver that uses it. Indeed, because the DMA pool API is extensively > used, this vulnerability is not confined to a single instance. In fact, > every usage of the DMA pool API is potentially vulnerable. An exploit > proceeds with the following steps: > > 1. The DMA `pool` initializes its list of blocks, then points to the first > block. > 2. The malicious device overwrites the first 8 bytes of the first block --- > which contain its `next_block` pointer --- to an arbitrary kernel address, > `kernel_addr`. > 3. The driver makes its first call to `dma_pool_alloc()`, after which, the > pool should point to the second block. However, it instead points to > `kernel_addr`. > 4. The driver again calls `dma_pool_alloc()`, which incorrectly returns > `kernel_addr`. Therefore, anytime the driver writes to this "block", it may > corrupt sensitive kernel data. > > I have a PDF document that illustrates how these steps work. Please let me > know if you would like me to share it with you. > > **Proposed mitigation**. To mitigate the corruption of DMA pool metadata > (i.e., the pointers linking the blocks), the metadata should be moved into > non-DMA memory, ensuring it cannot be altered by a device. I have included > a patch series that implements this change. Since I am not deeply familiar > with the DMA pool internals, I would appreciate any feedback on the > patches. I have tested the patches with the `DMAPOOL_TEST` test and my own > basic unit tests that ensure the DMA pool allocator is not vulnerable. > > **Performance**. I evaluated the patch set's performance by running the > `DMAPOOL_TEST` test with `DMAPOOL_DEBUG` enabled and with/without the > patches applied. Here is its output *without* the patches applied: > ``` > dmapool test: size:16 align:16 blocks:8192 time:3194110 > dmapool test: size:64 align:64 blocks:8192 time:4730440 > dmapool test: size:256 align:256 blocks:8192 time:5489630 > dmapool test: size:1024 align:1024 blocks:2048 time:517150 > dmapool test: size:4096 align:4096 blocks:1024 time:399616 > dmapool test: size:68 align:32 blocks:8192 time:6156527 > ``` > > And here is its output *with* the patches applied: > ``` > dmapool test: size:16 align:16 blocks:8192 time:3541031 > dmapool test: size:64 align:64 blocks:8192 time:4227262 > dmapool test: size:256 align:256 blocks:8192 time:4890273 > dmapool test: size:1024 align:1024 blocks:2048 time:515775 > dmapool test: size:4096 align:4096 blocks:1024 time:523096 > dmapool test: size:68 align:32 blocks:8192 time:3450830 > ``` > > Based on my interpretation of the output, the patch set does not appear to > negatively impact performance. In fact, it shows slight performance > improvements in some tests (i.e., for sizes 64, 256, 1024, and 68). > > I speculate that these performance gains may be due to improved spatial > locality of the `next_block` pointers. With the patches applied, the > `next_block` pointers are consistently spaced 24 bytes apart, matching the > new size of `struct dma_block`. Previously, the spacing between > `next_block` pointers depended on the block size, so for 1024-byte blocks, > the pointers were spaced 1024 bytes apart. However, I am still unsure why > the performance improvement for 68-byte blocks is so significant. > > [0] Link: https://www.csl.sri.com/~neumann/ndss-iommu.pdf > > Brian Johannesmeyer (2): > dmapool: Move pool metadata into non-DMA memory > dmapool: Use pool_find_block() in pool_block_err() > > mm/dmapool.c | 96 ++++++++++++++++++++++++++++++++++------------------ > 1 file changed, 63 insertions(+), 33 deletions(-) > > -- > 2.34.1 > > ---end quoted text---