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 EE3DFD6C2AF for ; Tue, 19 Nov 2024 22:15:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0395D6B0093; Tue, 19 Nov 2024 17:15:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F2AA26B0095; Tue, 19 Nov 2024 17:15:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF2BD6B0096; Tue, 19 Nov 2024 17:15:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BEF5A6B0093 for ; Tue, 19 Nov 2024 17:15:14 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 36E0E801F9 for ; Tue, 19 Nov 2024 22:15:14 +0000 (UTC) X-FDA: 82804250130.15.23F0D11 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id D95A5C0008 for ; Tue, 19 Nov 2024 22:14:49 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=plf8DAX9; spf=pass (imf10.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732054451; 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=UYbjhyANEBF5M6oYEB5+7TcBsRsiWK6oDBzD65KE6dM=; b=0ok/Gy0Kk96fagCPIeDPBmKTsQwNcHDOGQPoLU/D5wtslwAwG9svALlLqGw+u//TxNzg2P SYIVf8qLnDsvSI9OA4ySr70YyztfTATAKGMOAFcuKNo1/rEA44FluU8UyZZjf5HNcZrGZ3 9mcHMXdznqKkRYH2ilDfwn3ehX6vGfU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732054451; a=rsa-sha256; cv=none; b=7p+hc0S08AFF+8svV8ASMXf+nnOIIlWo7joVSFXAbiWSqfSp35KTddwgupAyHVzlE/4d04 IR1QT3KcejVJ6qNLjqxB7S2L3lveQaYi6XfHxt0FNySvF9Ov391K55bEnA5whlYI4AYjwo mgiUNQ/mIMQUEJrkUv9JGcEBMtGgGQ4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=plf8DAX9; spf=pass (imf10.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 367015C4CDC; Tue, 19 Nov 2024 22:14:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6501C4CECF; Tue, 19 Nov 2024 22:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732054510; bh=ldY6WBWPKHHhYPop1SiXo3e9JekM5N8ocuy8u2zGjI0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=plf8DAX9AAyb/t+kWO7ybvtl8xgHZHU2wBMyBSe7T7MptghG1YljV+CMUnAdTZpZD B7naqHX+jsKVD9z5M0GXSGyybB3lczKbYDrOt19gonje9YusEFR6QhY3Jx+6VeYPgh ic4o/wwJHPZ6Sk8kSIiuNjxnGZfFYivEpUeO/J8o= Date: Tue, 19 Nov 2024 23:14:46 +0100 From: Greg KH 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 Subject: Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption Message-ID: <2024111914-overuse-cider-7734@gregkh> 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-Stat-Signature: yiobsiugse8ifkubeqfntztxhipsgmzd X-Rspam-User: X-Rspamd-Queue-Id: D95A5C0008 X-Rspamd-Server: rspam02 X-HE-Tag: 1732054489-878411 X-HE-Meta: U2FsdGVkX18eMx3i65Li8bmDyiWC+CzKle/8M+ERFVcdYhUPyFziikADQVH0A5QXtUTHFUFncLbEWK3ZqE9gEI8D0HFlM+Pht46YbhfmztItyQeJS5UnH7oEvzqjSPUFJPydfWj+5vrHWxVyuOgQzIdK4eWJGSw4jyD9MuIzVnAF3vaEkqI4RxWyFTncFxwAkXNyigsPhBBwSQGroods2emx76wjjL6mnf/xefME8dyUSf6dnMjfobOeuiZ1GUNKRSqoWjLGGU+6lAmuIDuTMu0xxwtG3Tc+Q3LXCAMHf7Mr1NwHdBcJhuhAEA5006hOiwkWOkWt0nJ7HjtpDYAtuivASjrZpAcuusV1vNpsjLqK0RvCgGhitpewOWaCktNixjQReRwNZYfgxS4rso6JTYqge8UI3TePozV4qIj+9Yrj3zbYF1QcnCq/Z+Y7D7qLWpBXc2UsecgHKqM162WFAaH+oXYAsUu1kNuhwfO5uUDJ4KcMgP3stlDOrYc0fd2R2wCXU64zo8vTdBMu9ClIOLBmHdxLS5sbT0xeTrsEDkMqQKvw1fmh/GWIlDEJkwMmS/vruhcUR0TpRGAxeXP4RsC4a0fFAw4STANkmCzOjvwfUcBnksdBqcSfzoMMNkJj1ySUIiCZw2i3Zwn5IIPABJTDaYm72oAeMPC1Yp327Oi+xt4itWZ0L0dZc4dQ8UUw0TA6PEHCEqj0uQ7E9/dzd1wWFpJtjEavmp9rjyVV6avs6i3tDTv5EorV95XgDaKU/BWdfvVETde9dt35oG7OvTnSsI+eMwb4YTucs3DDFOuu72MfBCFAhIkbeH9oRRXdVbd87TzR408DdQDDa59QTClx7LvlH0S1on2XE6gSav+Vf3KYW6GkxQD03eSd41LAd4Ujn0hwJiLq15mdRwJNVu0F9Rjpoq2Jved+qroIgmCR+teWdGqDql7jT8xfOd+JxK62mW9uA/9a8uTxuOu XpF7DUDp k3mMsCzxUSg0iH3m3V42LjAeOiecghHjU6MTtonOvlmEYhA7hN4Sl//TKBwOVfQIVjYxCc3MvgPi7FrO90cDHZ3YJR+GP+Vufigpb3nP9v9sQK94HYCvkYiYHkM8XrZwVPl/zQRWXDz0KiNb6zKNpvHzQwgt1VgVPdv4wKEWFkhdzpUV5Fsaki7JkRpyT6vh6OBTtfH0enY9B9l/mHyBBeg0Gd7426kfb1VMMSE/W/ZiFRsbu4kCoC3f5e2Rg3SVA1XEKqcEhgnl6glJEhBBEhxlGzd5gloBIxMGqbinLx7ex95HqOXV733DiB9qVbZyw3vH2 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. > > **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. I know I said it privately, but I'll say it here in public, very cool finding, this is nice work! > **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 > ``` You had mentioned that the size:68 numbers were going to be re-run, has that happened and this really is that much of a boost to that size? Or is this the original numbers? thanks, greg k-h