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 2A422CF34B0 for ; Thu, 3 Oct 2024 16:50:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EFDC6B046E; Thu, 3 Oct 2024 12:50:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99F726B046F; Thu, 3 Oct 2024 12:50:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 867476B0470; Thu, 3 Oct 2024 12:50:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6528F6B046E for ; Thu, 3 Oct 2024 12:50:44 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1A29A14191D for ; Thu, 3 Oct 2024 16:50:44 +0000 (UTC) X-FDA: 82632880008.14.D7FF5FF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id C74D640002 for ; Thu, 3 Oct 2024 16:50:41 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=poxfzoyS; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727974137; a=rsa-sha256; cv=none; b=p/ZC2oak+yj7xjxxi1o5HD4EUVJZ2c/5nAd8u8NoRRigzGIV5FBjHPGlDwTMQ0JiVro6fB K5UgfTReDaWy4ea+K1oj7SOiz+fxUQl+nuItT/bXk/pjzh6/eFfyVkpmvrNihwIOU0i8W9 E38P92vFe1Vre0cpNtfUVR1tSTFcA1w= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=poxfzoyS; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727974137; 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=/uZvMw3p1nhrUm26IyzS8D8wAdQar3LohH6y2c2zRNA=; b=t9LsdmevkS9+qOR15Zi3E+ZSUK24KJ6rQFqVrLX15JxxpC4lJ+o8BHEzAAMxE6lU9YPmxo SqQO3GbVDcUCRyoccy80Q5TGk1Rct0SfSIdfKvibkp/Gtx+Jwcq0dcVPdN/TF5YU2nqXMo qm1qBYJrlI3+LCDraC8gSTLQS3YBUDE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=/uZvMw3p1nhrUm26IyzS8D8wAdQar3LohH6y2c2zRNA=; b=poxfzoySLhEneVmzEJeNw5bVq5 FHnKtcAwOOl9IL88ZX2pbyLGp0tNTbzmOQWTOTqplm7C6DNuuKzJhDUqcsYnXzFe7H3YqKyvh1jcd PWs4MXKLviewYDrectMj8m8mhx7U6uj2FR/phBkIkxx3x5m0BIm4k46lKgztyDUFP32bcr8gA9Z/n be6YvV+aOJp7GPakHTm60X1kaqeScc8/KNvGyKY87VeOnkqCSUJSHjAUJE7/zV3gM3638mC2uBTUQ PdXnmpZtCylwx0E50TS2qI5TP3YeJoXn17tl7bdI7LbHr/3QkcIU5hJYon4kpdqXsXqcd800NR8lz 69dwoY+g==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1swP2F-00000008HJj-2mzy; Thu, 03 Oct 2024 16:50:39 +0000 Date: Thu, 3 Oct 2024 17:50:39 +0100 From: Matthew Wilcox To: Vlastimil Babka Cc: linux-mm@kvack.org, Kees Cook , Jann Horn Subject: Re: [DESIGN] Hardening page allocator against type confusion Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C74D640002 X-Stat-Signature: s9nouf6uusrfjyt11f1jt85huz9oq7e8 X-Rspam-User: X-HE-Tag: 1727974241-747935 X-HE-Meta: U2FsdGVkX1+DxnVULoTzNuLB95mWe4ZMdQiIfNLbxtkKhi4dUDAOtKqikx9F0F2WVib/OUa/oxYAbtySQtHM6j282AG5mv1FHRe3WggXOm5tti+q0xv6zsPFB3Nm6/ttNnPpe6z6mDw0F//4khIK3X5knrmawdzvsEx0N0/pR/AkMohwvLOyru+bvEHih2Du6uVZ0vUkW0CMVIro065hjTZ9rPhS54w2uk61vuKl8ISJZHP88bRr0ZgERiO+EtwUDthh4r+87oLdQzCIRn0SFOAFBo92HixIoW2t2EciI6bsSGCHElDJZbndy7zTNRDjRcvHzREGW0rZBaoGdot7i0DzwP0BkxF7IR94efFIWbqMUl8LSBLjs1kYF1GLRGpd5VILmkbN9a8H2KlTEj2yi1hxRmwpFPNLWT4OZb79Ck4hLh02rL3f/CdD+m8oUBnp4OHIEZzH+YjzT6c5SKK0Cy/3W+pnUlkw8V6g1xnXwdR6S+DsCGLDTknwjWFNZQqvvcWyzuvR2/14JwStSm6T96xc29Ct5JPKQ9IAXAK+XQo51efl/9NGRxrLrdKfLeydHlDF5mCf/FhZ4EPxxc4fzc3w1XMslWQndDrG2mGvy29B3WFXZSmabytXxUPW+l/bbelfRoX0ef6vBbMKf/C1wtqjKrUbtdubbXJXUPJOtiNk5sv9GMTcqXB1sD6CPY2ayPy4PZkV3j1Lbb9EjiMdopwTTzutcwnT1QuJOGYCCBRh1Bk7/YPA1Jf78AQDYkd/LpqQXuU/k+ZsveuE8UXZGHswXRMuGTkvv94D6CxYXzrk/UWWEAsHXQYfFM2Vs+bS8Hqg78eaf3RBuzWATDwPU9QUpgo4o2rWDA+8gi8Zdqz7+rfE7G8Z80FLjK96YNRsov/1mPBo95XZyNPzmluqNdVhTMHAqtA6JUC6xiCF9O2Qdfg6r7Km8FDyTDPMkh361KyXLrONMed5oy/Ok9k io+ccZRG LfuTXyh8x4eliAxaRics2dKN72Nhk7HlkEEi14bcYSzr1Nj+g1CL5aKBl2MCpME2Dth8z8hJ9dU7G6u7a9uUfbQ+1iJIJHrvW88eh+YlYXb18HL7Fu8clmkjTeEhuJOBXet5Y8cuHFrkRvG7xvc8B+Yo0E+WG+AZKZ189KPjFka90cIU2edn6J0viULJsBTmkG9oFvClohCKrpRSOIpElBcUiEtReLPFnhSM2kGf1hmCBHpi2zSYEofo0N837A4bwkYPpK1WaS4phLjhN1HTsG3nxEkquKgRTUgO0 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 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.