From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AB6C238C29 for ; Wed, 18 Feb 2026 19:57:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771444660; cv=none; b=bJmfUEzKzZ7FKFki9Za+s+mQqPqahF4zbRqZmHEgHv9RPoWAuPS3NmA6+pSH/HRc6SL3+DEQ9/odB+8otyWlH8aJ4n0pQ3JQnNqViRE+f1MvBCMQjl7n7m+ptThB9scf37byf5STrKH8lvcMwOioEUffIWhYmuZh9stXFsoHK4I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771444660; c=relaxed/simple; bh=zNOeFZ2gT2jJT7+OyMhtzn45kQv1TGbruMRIrZ5ravo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=J+KZlXZmjOP2XiqPETePRFpuwS4sQZYeJLrnoSklZxOhokqVV/Laj1TbwmpDdNZs3H31wwZGMCCKzQdiRpdYR5WoHeYBzVjruxRQT4+CkFalyNCc2wzekKTuLiiVF5OvftGA/IUYSMtqE13kPP6aB/W8BZXl9p+3F2KUCf++77g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b=KLTQ1EtT; arc=none smtp.client-ip=74.125.82.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b="KLTQ1EtT" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-12732165d1eso161134c88.1 for ; Wed, 18 Feb 2026 11:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc.com; s=google; t=1771444658; x=1772049458; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=iKYkZR4doNKAqI71WoYaMA5DL3zj5NX+5I6qS1ZsCY0=; b=KLTQ1EtTrLiJsViYMv60Exu+5fS/QFa1DUgCrsLyo5rNUUT7FOlvyUeuyc+X9VXkkn h4vVVItc/7zCfEOBJWjdD20clVdLHgfk7cdjAB5l3UIQmgsHFYiBmBnVvsNUeCLLZKkQ gTQrA60SomSx84kHxlY1nfeOUyQBAnoO7fS4X5lsHOc3kpTAYtf7/o1HXD6rpoo+MUt4 d7ON8KiluGWN5b4u/P6/Am8oV5d9R4q0np4QFQO8MikNHkovADCgq5MffqbGEplLw0jv QIbeuoQxmLjLvuLG8BvSh8Ekw0BttcWfeQPdpCFZLZgV5d6BTJWI3euZzVfEINiSPXx3 on5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771444658; x=1772049458; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iKYkZR4doNKAqI71WoYaMA5DL3zj5NX+5I6qS1ZsCY0=; b=Ku/jlE6qGPXgoMh97MgGC7og7Rg1hNBkQBLkDh79zQRjWUk0tqburGHz8wOnusz184 ECITuzsP03kQJP61sq+/W0Qdfct1rBYzg/fAzniHsJLtcOB7scBWpycApePnkklgzUyw 4aMCjYFLDV09A+ZrcbpFbm7LaILX3FILOXAF0UpuV6XP8qOvn6dEBzFOnWOpLtS2k/Po AsGp4Z6zOwDH6UzI74ku/3Z/jNJZG0lTeyxHLEHq7aWUZgLyvI1zLOEBg5iVy9jKvQdt 6UO9pzmloE2R50rwG84CyHVuOIG5KoSTIh9qLo+C3EBA7QTficfoZOwU8POe8spr74lm Z5Hg== X-Forwarded-Encrypted: i=1; AJvYcCUo7VY1glnN0EaqHyjhrwZvyZbA1Gfc9dtEkhT1dC5Btde6UiNk0v+TL/GsTrH9z5HpFVP7YSw1YqjMRbY=@vger.kernel.org X-Gm-Message-State: AOJu0YzJF97J7MJgVc0HZGYnLfvzgTRqHMgiO6WMuoA6/MxGQImSQ6Iz OZZ+zIFdgoYn09DC+bgWUMPhVSNhMZknWIq8xYgw1AV9zoFIeug7J9aEkC96u0gF3e8= X-Gm-Gg: AZuq6aL/qjhUKdw7dQvf2cLNTcmbBzVwHlyrAJxM0rumGntj3RF8WiLE36vtm0myNMy XEX94/Jc9xQxUE9DTK+HwEd4UePw22fuGrWR9bD4NwK5Dvc5A6WIXApdQVa1Ue4ar6WPlIpj8T+ 6lHfPFJR1ZMcR7zSb1hcoHgCbEyMu/JLoXifq3UzID+4Oxn04tdG7nDRrj0aqFqEEiASlBL9hKm HO59nDQfl7b29awdgAfIbYz1XgXWcI25B9usrIRc8+bkcqjXAheOWSzZIcaMabAVLwx8v/8S1GB McSz2+1dOTPWvPFguLRYMPK2mPFfzXu4hH9+F9W6NvIRZVelI9LjWDoBvMd/FP8kcruMuU3Xj/N P03kiiZbRAnyt9xpEjMdZo2v4y9zJCKh9Bk/MIgHncygduyy0JCn7hUOm3GtJ7e8Gr2K3JUYSvQ 3f7Vlic79t0zpxrinxOM9AENis7rA1yEvA X-Received: by 2002:a05:7022:a81:b0:127:3b1d:f593 with SMTP id a92af1059eb24-12759a043c6mr1438756c88.9.1771444658229; Wed, 18 Feb 2026 11:57:38 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12742c63feesm24060077c88.4.2026.02.18.11.57.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Feb 2026 11:57:37 -0800 (PST) Date: Wed, 18 Feb 2026 11:57:36 -0800 From: Deepak Gupta To: Linus Torvalds Cc: Mark Brown , Paul Walmsley , Thomas Gleixner , Peter Zijlstra , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, zong.li@sifive.com, rick.p.edgecombe@intel.com, yu-cheng.yu@intel.com Subject: Re: [GIT PULL] RISC-V updates for v7.0 Message-ID: References: <2248971d-d69c-65fb-93b4-10f0d7d8bbad@kernel.org> 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; format=flowed Content-Disposition: inline In-Reply-To: On Mon, Feb 16, 2026 at 01:55:11PM -0800, Linus Torvalds wrote: >On Mon, 16 Feb 2026 at 06:20, Mark Brown wrote: >> >> If that's the part I think it is it's following the same pattern as >> shadow stacks, originally inherited from x86 then generalised. > >That makes sense. I was looking at the speculation control ones - >which I honestly think are done much better in that they are a bit >more future-proof and won't need yet another random prctl just because >some architecture comes up with a slight variation on a theme. > >They don't technically do the locking (the speculation control has a >different kind of locking), but because of how they do things - by >having separate "which control do you want to change", and "how do you >want to change it", it would actually be very natural to make "lock >it" just another thing. > >So I actually wish we didn't have that shadow stack prctl - or this >new one - at all, and they'd just use the speculation mitigation >pattern instead. > >I think the shadow stack case is probably too late to fix and people >presumably already use it, but maybe it's not too late to fix this new >control flow integrity case? A little bit of history on this. I was at Intel back when Intel was trying to enable support for "shadow stack" and "enbranch (branch terminating instr)" feature. Given no other ISAs at that time had any notion of "shadow stack" and "indirect branch tracking", IIRC it was advised on list that "shadow stack" enabling for x86 should be done via arch specific prctl. Yu-cheng/Rick Edgecombe can correct me if I am missing something here. "x86 indirect branch tracking" enabling for userspace never made it to kernel (although most distros when they compile userspace/packages, `endbr64` is compiled-in so that whenever it lands, enabling is one step away). Later in 2022 when I started doing work for cfi extensions on RISC-V, I started with arch-agnostic prctl for enabling shadow stack and branch tracking. I was hoping that all arches would end up converging on that. Soon Mark Brown sent out arm's "Guarded Control Stack" (aka shadow stack) which used the arch-agnostic shadow stack prctl. So today we have - arch specific shadow stack prctl for managing (enable/lock/disable) shadow stack on x86 - arch-agnostic prctl for shadow stack management on arm64 and RISC-V If we land arch-agnostic prctl for enabling branch tracking for userspace as part of risc-v patches, I am hoping we can leverage that for x86 "branch tracking enabling" as well. I don't know if "BTI" is enabled for userspace in the arm64 world but if it isn't then it can use the same prctl. This creates symmetry and convergence as well between major 3 arches for branch tracking support. Furthermore, Control-flow integrity is shadow stack (for backward cfi) and branch tracking (for forward cfi) both. It'll look odd and ugly (to an extent it already is because x86 and arm64/riscv use different prctls for shstk) that shadow stack has its own prctl and we invent new cfi prctl just for branch tracking. Ideally, it would have been nicer if we had `PR_GET/SET_TASK_EXPLOIT_MITIGATIONS` and sub-codes under them to enable all sort of things like "Manage CFI", "Manage memory tagging", "Manage speculation control", etc. But things evolved on their own pace at different timelines. Given that we already have a fragmentation in prctl space, I propose we go for arch-agnostic branch tracking prctl and let other ISAs implement support as they go about it. If you agree, I'll let Paul choose the right name for it (given that indir_lp isn't a favorite) > > Linus