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 A10CDCF8840 for ; Fri, 4 Oct 2024 18:01:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 925F96B017E; Fri, 4 Oct 2024 14:01:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D6146B0181; Fri, 4 Oct 2024 14:01:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 750E26B017E; Fri, 4 Oct 2024 14:01:34 -0400 (EDT) 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 541F06B017C for ; Fri, 4 Oct 2024 14:01:34 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 07B66809E4 for ; Fri, 4 Oct 2024 18:01:34 +0000 (UTC) X-FDA: 82636687308.04.A5D2FE3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf22.hostedemail.com (Postfix) with ESMTP id AB063C0005 for ; Fri, 4 Oct 2024 18:01:30 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DJzLJInu; spf=pass (imf22.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728064849; 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=MJRErlwJc5JIoMIJg5CPUXupYMjY90AM4kkKaVpd8Ew=; b=MaQXZP/1yMMilbn+2Qkosav7QiTWpybsriHLlcgyvZzQ+1t9QZQKz1wukLCT18K7dgEHc3 WFPych+WNEIM3Yfi5YMzIY2Vd6koCJDuIEWbF1HL5S1++Ctz187aaM4nckcO6k/Lh3j+1U g/TK25mKEaQtdjN620pZkLM5sOLlU5w= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DJzLJInu; spf=pass (imf22.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728064849; a=rsa-sha256; cv=none; b=SwtNaYH9tZto0RaRe9yV8GW5pbBdpVjKmSc1SXlGMLRb130e0JnY7N8c0GwrecfYfNLpEw UEbHmtiaj/dym8swFt0WzjiKQuZReiv6vZdwYrGb/XG1IVyw2JdlhNKGkmjvDhaGj73kUg qRQjCecedh3tFsFGeIMhn6OHQx9QENk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8913AA44C43; Fri, 4 Oct 2024 18:01:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91CBFC4CEC6; Fri, 4 Oct 2024 18:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728064889; bh=qspKJeW19EYJ0pZQoeHFjsDehQn2PBhOZLh3ja6V3Lk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DJzLJInu7yClhtk7mRGk1QMnNW9F8Bg/fx/Hhv6pRib3sAHAuBBeJG0Ja+pZvUx9S +VuTY84SwMxm6tXnPpeIsQ8sF4zCr66VlPMnwRDNwlzGz4EAbYbEUEuKZmLYV8tf95 lAZgjHL6n8e+58vshG3pj/mSuXXAeEPxC8MeEDYE/ei+Otj1OTi70Lobp5/hLGslLe EdQsLjKYEYxJscgnCxmZqiX+xYj/IB/QadV/W07YkD18XdgSqjTjRkmvcuDHUrNqf1 xRFEkRwvHXOoKkL7XqbKk5V0kCq/XAcXgmanUa3Scdz50rA0epWbx3OeE+9vTc6aLI JOVVJGtGaSFeA== Date: Fri, 4 Oct 2024 11:01:26 -0700 From: Kees Cook To: Matthew Wilcox Cc: Vlastimil Babka , linux-mm@kvack.org, Jann Horn Subject: Re: [DESIGN] Hardening page allocator against type confusion Message-ID: <202410041058.AFA68FF11@keescook> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: j34aisz134itdjcodqoqdmgjoe5stjid X-Rspamd-Queue-Id: AB063C0005 X-Rspamd-Server: rspam11 X-HE-Tag: 1728064890-237003 X-HE-Meta: U2FsdGVkX19kzs4WJKEfJeQrL4dmaObw7zBRxM/9MBA6OKkgyqFnzlZGP8WeJnKYV+WQjHLWYjVN1jBytc1AoYmdB1vV33zU4Sy5PvmaNbhwMNJthEACS12FJCy0bMnsTTrLKpTjPnDZ8vIre0TtopS+/c4kknwCzHPg27djNpvXYG0FoACeFMzdurbqKoFmGuOlP4gW/EoqlAd5mrinOaYMs2Kar1fZE1GLPZXkw39rpWcL7zCj5BtY8Bx/zQeeYQeuTfYXsBRN5vwKCd0X0FWhCm3ojaWTmrLFDEWTx4LGcM7H5zJP9aOkOFy3VLwyXV1gs/0fPUux108b1Dl4AjAonf7lRq97Ni9u2kgWfuiV1SNSfx6dDArQaAiSOAkAi63Nzb1XeiGcYNUjaLCYXSOL28sW0iFzox6sHY6sTgiphVX1FCfOnRrVMO90Dpq8+gO3+krFZocAZSD+itYIeCx6svQl4/7QetDpWlQ7g3yrn16XsDhO4T2nMhQQoH/KMu1PqGIKRS1/t8782HK4C/xpyXMLicS3HhEf5tQLj7x07StXgBJ4vfZb80myukl1D28oQ6hdhQUDUiWuNFxc3EQ1IJJF4p/PL6LfBRucwI/sCBIZ8LlghAihi91VFVH1XtY0RSxRAx46F8LAn323U30X+7oOSLexTxo3AS359AagH5FX5YglDnhZBCIvIj/yM2Gn1LI61SsPUtvHF9QwYzoKUo0HrIibPk7+oHcqiF95P8X2kBpGlyaUYIaeeNZw9zdbo/FMJpS6iNnHnNh/63BSAP0aep3N0CdHEBVV+1jix0zscQs5PqQM6Eo6RIy+7pcojKna5wU3M14yvc0BHvIKJZznyseuZeMBjx9LaHZRsAJXN9hfZoyEbPj5LvmJlfKK+KV4iB2ONjOccTCs4o60mV2d6SP6NoNjwdXb1w9sMM/EImOwW5RECMUkJfVGwXmPmzjN9HolI7Lggh5 WjVIor6x 1HrNFxr58RNqEf6rF6MwvnCGNr1IRtkWD6IIweKUAvBXxWNyjVk0rsMSA8pMGdDb2eQ9W1xuxtEej4TL7ocGyzOwMPtWh09JiodDgmNZEVCoMco9PAOUT+v8azIKlkAnaSR7AM3KCTTGso4dIvbUqvH/kAVBB+a35bFu9EhOiZZCSlMf1Uikwa1svJkA59EUKTiHPfbfqgZq9zLMWN2TKuIP74PZyFCZKl+Vmol5YtwNtdutbVjdLUAs5yKnuNRvNFQMx7EaqKW9BzkETIcoeANc1TBhKJnfrKaakU01eunSTwMQx6x6S0HIKqQ== 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 Thu, Oct 03, 2024 at 05:50:39PM +0100, Matthew Wilcox wrote: > On Thu, Oct 03, 2024 at 04:27:12PM +0200, Vlastimil Babka wrote: > > On 9/25/24 21:46, Matthew Wilcox wrote: > > > Kees and I had a fun discussion at Plumbers. > > > > > > We're trying to harden against type confusion, where we think we have > > > a pointer to one thing, but it turns out to be a pointer to a different > > > thing. There's various ways this can be harmful, which Kees has laid out > > > before when adding slab buckets. eg see https://lwn.net/Articles/978976/ > > > > > > Not all allocations come from slab though. If we free a slab object > > > and the slab it was in gets freed back to the page allocator, it can > > > turn into almost anything else _quickly_ as the page allocator fronts > > > the buddy allocator with a stack of recently-freed pages (called PCP, > > > not to be confused with percpu memory), so if the attacker can arrange > > > for a page table allocation to come in soon after a slab free, it is > > > very likely to be the memory they have access to. > > > > > > My proposal is that we resolve this "type confusion" by having separate > > > PCP lists for different types of pages. We'll need to have this for > > > memdescs anyway, so this is just shifting some of the work left. > > > > > > We'd reduce the exploitability of type confusion by using a per-CPU, > > > per-type stack of recently used pages. To turn a slab page into a page > > > table page, the attacker would have to cause a dozen slabs to be freed on > > > this CPU, pushing this one into the buddy allocator. Then they'd have > > > to cause the allocating task to empty its stack of page table pages, > > > causing the attackable slab to be pulled from the buddy. It's still > > > possible, but it's harder. > > > > > > Harder enough? I don't know, hence this email. We can get into the > > > API design (and then the implementation design) if we have agreement > > > that this is the right approach to be taking. > > > > Not a security expert but I doubt it's harder enough? > > > > I thought the robust mitigation here was SLAB_VIRTUAL > > Well, this is for allocations that _don't_ come from slab. Like page > tables and page cache or anoymous memory. I'd really like to hear Jann's thoughts on this. My instinct is that if it makes it harder to attack but provides some better performance or reliability characteristics, it's very worth it. :) -- Kees Cook