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 57A26288C96 for ; Thu, 26 Feb 2026 13:23:54 +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=1772112236; cv=none; b=WZqajQ47ot8Cml8mU5xq8m/IKlhJUSzgIMxLTEzZ9eXvounqlGV7mBpVomSG7ucWLpWH7X/dTKEALxeXGO9SzKXja+pV7o3QMtsADNvgo9cP4tNqJyL70ik4Rpi5a9EAcKC2UbOxHWYLgIiimryZ+RKZyj+VzBtnLgYimCPsmdM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772112236; c=relaxed/simple; bh=Ezx3bvRi8IL6d95NOuzaiFIXaFhXkcxN3/r/jp9akoo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r3CNhiAWxubdbBC1oXDlMoChXPJ3d9G+hjVlz7QM7KEeiiZq0NhFc+z2jjcU7s92x2j+ZyYINdglAMpcuieDSG15HEx8nNEc5hbAiZSbr4Yp/UmP9ilD1xBRMp06RlTlePt0HkMDv/E4jgMEfUwX/d8cv52kMonect3LJOtP6ek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (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=Y5vwKzVh; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (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="Y5vwKzVh" 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=i2vPnTOsLMU5Qa9GYDYYtRH0azuc/q1gEYWuAZdWaDU=; b=Y5vwKzVhCLbBxLqiCsXJ/0jL6+ 0ZDAi8m7boE48xT0Toj8otIFjpXlvlNPwdXlxxqGvJGl8vKbksxWQhA8u84xRRm3GRq7X1buiUR32 7COui8aDmjUKbqH2MbWvBj6nHWo5GDKTltn52gHNDicXbNX1u4mVAuiMIEsJWlrw5+hZMZz3O1hNO ggh4U0Z6Ob0lgxOPGup8LNvQpTneHl4sHqbZeuvEcQl4r33DF7yM20gTxSA06Uf9lSF08kYWCiAUb sdhGMZ1KFveCBWRtDPWuMQv/5GWMDePhWy7ijsuP/4L9bh6B1RqkrEwsr4XyJYkXx+buHK7RCviuR y0w70gZA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvbLI-0000000B21B-3wcq; Thu, 26 Feb 2026 13:23:49 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B35BF300462; Thu, 26 Feb 2026 14:23:42 +0100 (CET) Date: Thu, 26 Feb 2026 14:23:42 +0100 From: Peter Zijlstra To: Deepak Gupta Cc: "Edgecombe, Rick P" , "torvalds@linux-foundation.org" , "Yu, Yu-cheng" , "linux-riscv@lists.infradead.org" , "broonie@kernel.org" , "pjw@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "zong.li@sifive.com" Subject: Re: [GIT PULL] RISC-V updates for v7.0 Message-ID: <20260226132342.GC606826@noisy.programming.kicks-ass.net> References: <2248971d-d69c-65fb-93b4-10f0d7d8bbad@kernel.org> <196537b2933567d1781901f813a72ffffedd10fd.camel@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: On Wed, Feb 18, 2026 at 05:57:45PM -0800, Deepak Gupta wrote: > x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it > does have mechanism where a bitmap has to be prepared and each entry in bitmap > encodes whether a page is legacy code page (without `endbr64`) or a modern code > page (with `endbr64`). And CPU will consult this bitmap to suppress the fault. So; all of this is only ever relevant for programs that are mixing CFI and !CFI code. If a program has no CFI, all good. If a program is all CFI enabled, also all good. If it starts mixing things, then you get to be 'creative'. Now the thing is, if you start to do that you need to deal with both forward CFI (BTI) and backward CFI (shadow-stack) #CF exceptions. That bitmap, that can only deal with BTI, but doesn't help with shadow stack, so its useless. My proposal was to ignore that whole bitmap; that's dead hardware, never used. Instead use a software PTE bit, like ARM has, and simply eat the #CF look at PTE and figure out what to do. Yes, this is 'slow', but my claim is that this doesn't matter. There are 2 ways out of this slow-ness: - fully disable CFI for your program (probably not the thing you want, but a quick fix, and not really less secure than partial CFI anyway). - fully enable CFI for your program (might be a bit of work). The whole mixed thing is a transition state where userspace doesn't have its ducks in a row. It will go away.