From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F1911C5F39 for ; Thu, 23 Jan 2025 21:50:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737669051; cv=none; b=uz1bCUvGeOCvO/MCgh9SRL7FglgOdu9OlJU7JKCuaFTVCSMCyeOTDjh+GtwEyAigDIVdLIyimcsAg3jcCzb5XMQtxgXuDDQ4EEvVrmOpOKoH6LziKy28L+wnkujF2504GjZ/czEIj6Fi3G3e3DwOMxg2hJp3k++9pQBMy83cpMw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737669051; c=relaxed/simple; bh=i0095S2JUQn4lx+C7OWHss0TbRPhVcdu06rlSyUzN1g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LQBCjQ6EaffL9MQwq8YTyxRRS1LQftQdtvLc3htzavlGJvuasvuLhb7OrguPwfwJev+0iEnSv39kxc1vl7ar/t1SSRUQV+yBLORX13JjBLgAKSqmbT99rgbY3m7t8pF1Ra0bTmX6DXyTw8/lOGjkyt0JfikV8WiyazF8neB8Rb0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=YKBQ/eDH; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="YKBQ/eDH" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=Cd4BmaLsclIEkiG7XP4nn5tl6Bg6XsVJo81Baj4LnxQ=; b=YKBQ/eDHg6m/DBEUoG34jBtUnC IKDJ7KGP8SAja7cLXPc93lXyByoNiUf2jlU6TqGsLdOVDW5NDENRPmE9an6Kl6+aThbcqTOY0RETZ Yz2covv3xx3pWfa0J5FA/QAYnQli+GNQTmUc4LRPxeMi3grl4vlcngqT6oN1wvi/ezoWfGjssFtca +/0YXbhg4fPdqRupZBgnt/7TlAEu74wcn9zra+JvYBjOFtTnvFJNupw4eEVcGb7tUjnNt5kkko+Zw 1TpTZSEn9Vt3m9oTXMqYfWC1QBw4h6mTJCBpDtAQb1bYUdBDFSrAd+Y2jTWilFK59a/+Vr/N4liTW hGqvxqXQ==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tb54b-0000000DqiQ-02Ve; Thu, 23 Jan 2025 21:50:35 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 135B63006E6; Thu, 23 Jan 2025 22:49:12 +0100 (CET) Date: Thu, 23 Jan 2025 22:49:11 +0100 From: Peter Zijlstra To: Dave Hansen Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, bp@alien8.de, joro@8bytes.org, luto@kernel.org, kirill.shutemov@linux.intel.com, rick.p.edgecombe@intel.com, jgross@suse.com Subject: Re: [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling Message-ID: <20250123214911.GB969@noisy.programming.kicks-ass.net> References: <20250123172428.D6D8C8D9@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250123172428.D6D8C8D9@davehans-spike.ostc.intel.com> On Thu, Jan 23, 2025 at 09:24:28AM -0800, Dave Hansen wrote: > tl;dr: 32-bit PAE page table handing is a bit different when PTI > is on and off. Making the handling uniform removes a good amount > of code at the cost of not sharing kernel PMDs. The downside of > this simplification is bloating non-PTI PAE kernels by ~2 pages > per process. > > Anyone who cares about security on 32-bit is running with PTI and > PAE because PAE has the No-eXecute page table bit. They are already > paying the 2-page penalty. Anyone who cares more about memory > footprint than security is probably already running a !PAE kernel > and will not be affected by this. The reality is that many of the mitigations we have are 64bit only. 32bit is known insecure. There is absolutely no point in using PTI on 32bit at all. Can't we just rip it out?