From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 F2513221723 for ; Thu, 19 Feb 2026 01:57:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771466269; cv=none; b=DT6LrOvBoegg+hCzifg4IC2A0jKOTV7S18hyDSDQN7hxoJSuwhjLI/J17BexumARyjeK+6HxRCNs5sm34gM3OhmkugoOlgGWF2RgjTJi1XXDIJRVm3JVKzs3ZQe1oGnAMqBBpn/CKr4JWIlCyIAmZk3ed+cjPhx+MSnk0hFvRn8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771466269; c=relaxed/simple; bh=kbgPBOde/DV0iFwio0nZcnhbWlZbVeT/v57oSzMtfNY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HkmA7hhlSzjrS4wCY2f8raBFLpUr4xz0hS6jf9fAEuhclySPht59KQjcyb2bgtKNr+EltvQZSOmYxHbLeG5HkeepGnrragW+RPTrlaLdaZ/n15ktIqNjfFTLBMulgXM4X0s3qR8NctKaWrWVcVypSfED7jiQb/08AEQK4aK5p+U= 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=czHdftyP; arc=none smtp.client-ip=74.125.82.177 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="czHdftyP" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-2ba68df3687so274675eec.1 for ; Wed, 18 Feb 2026 17:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc.com; s=google; t=1771466267; x=1772071067; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=DIxbBlPbP8TJgRno8AcCVRuKne7rBLgcVpvlMJ31i4Q=; b=czHdftyP02IUiHsocNZLIkJIws8ucBTSH9qhiJ2U5/yuv1fS8VyJyzsrFOVEqzoq3J XrjiyT+omlD1ohKvKf1+T+gJMUR2LstBXQ8GL8JcDoLmKB20oqIn7p97HIyrnCSpeHOK iSobd6/yDnfNgCGlRmNSlKlb27cRU6Numy3pr0zgDjrDn/IgONTZQpthbPaH0Bjga49T E+mjX1kGu2UeVnRi56nPH0mhWKjlKg+JxV2ob/xv1vHmwzrkrgscE7eg9oygWcVoIr0K nz7roJRqL9z2fe1FycuUoQTdo8lEChrEkS/JhkW47arcLuRe0aVlFon3oVSOH4nHzafT wQzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771466267; x=1772071067; h=in-reply-to:content-transfer-encoding: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=DIxbBlPbP8TJgRno8AcCVRuKne7rBLgcVpvlMJ31i4Q=; b=mn4iYnOXJ1/4XOSNavwMUqPN4h66TsNkbZqiLEVfIJo+ckzJlZfDOyOB0xfIXXQiaV 7uf5Dsgm+KAkVRnjyv8Nhdh92/rlBxToGDNgkQ2lN6rG/xOSf99u3EbGoFLurGvAXt8I Bqnyg8o/aljEwWSwFny/V79HsFtWaWFu4DHfqKg6vZY1c+u4+R3JqZjh8ivO/YWfSVU6 xI5MzHtuAgl92mQtyVErz7nA+gdY2M9WG76Ts8rMfVdSf9jlrL9Owpzs7nkrN8Eo0+jU J7bCt7B697el7uCqaxD4+ori2EVbhPjyqWNlrJo3b0Vfg72PFkajGINQmvc9MwS3j1Xd CQQw== X-Forwarded-Encrypted: i=1; AJvYcCWtveUQUH6kFcFVPYxUSxTk19aBfuimmRJOEC2gFQs3/l0RLXJZN1cHA44vm4eSgC6IQeqa4CekA1YGedQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2TqLaDr6kgKKMWKABcSNSb1UgQOct6s8Q+fcNTruZfPrJ48cb 1DEfPfnj76xcU46aUub8D3Vqi7AuvdfJ8uCh6+HMJcBPXno6KSyAiOhdn9BjijdB3/I= X-Gm-Gg: AZuq6aL31QzzdD/FDH1KNxfH91UrQf6EWNoCSCxnzDhUqP2O2mmEeHYFpJI32RXpJt3 js03rnTZO4W9xZa5ZKQSpYyUUNeQvVO8c5/czPVa3k9MQucJFyN35S3pClhx9rYCzqg5s92lggh 1yen2xB9pduEFbk1+dQRyQuxsXYAbMFLLYmiLV3K+cGROx6b7LDo4Hz989Z8dTNqJ1u9cQCw7Hc fNbh66diTgUVlcYbNRqGVMQFsHv5XHqIlNKXhlqPB377WFhJU8uJRq0O8FivjLhgynuHc92LTKO QTgkcdHOFu+ZGiYz4QOOPTyzee7cttVQM9b/8+Ni7H/yCdhqUO3sd1yChuWYFDdoOq6SNKhBs4Z gCpJBvdtJrFj8gUvk3WwPv7i2hYaXZcZEvSB2p9Ekpe8rn5Bj7RpdRua0Ej29dxMNwM9mZgjy09 eLFLeLKEnvbnYXB0SuvhwKFBsQM48p3T7T X-Received: by 2002:a05:7022:1609:b0:127:3480:7c9f with SMTP id a92af1059eb24-12741b6364emr7860691c88.10.1771466267033; Wed, 18 Feb 2026 17:57:47 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12742cba192sm19547183c88.13.2026.02.18.17.57.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Feb 2026 17:57:46 -0800 (PST) Date: Wed, 18 Feb 2026 17:57:45 -0800 From: Deepak Gupta To: "Edgecombe, Rick P" Cc: "torvalds@linux-foundation.org" , "Yu, Yu-cheng" , "linux-riscv@lists.infradead.org" , "broonie@kernel.org" , "peterz@infradead.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: 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=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <196537b2933567d1781901f813a72ffffedd10fd.camel@intel.com> Hi Rick, Comments inline. On Wed, Feb 18, 2026 at 09:58:41PM +0000, Edgecombe, Rick P wrote: >On Wed, 2026-02-18 at 11:57 -0800, Deepak Gupta wrote: >> 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. > >Arm already uses PROT_BTI to enable their landing pad like thing. It doesn't >need a prctl AFAIU. Peterz had been suggesting we do a similar PROT for x86 user >IBT. Although an additional prctl might still be required for x86. We'd have to >actually start taking the patches upstream to see. 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. As of today almost all distros and packages are shipping with `-fcf-protection=full` compile flag and that means all userspace binaries should have `endbr64` compiled in (i.e. modern binaries). To be very specific, anyone using beyond 7.0 kernel (that's where x86 `endbr64` enabling support will land) is most likely running latest userspace on it. Anyone who is running old userspace anyways is so behind that its likely plagued with vulnerabilities that an effort to enable cfi on it may be futile. So if x86 were to follow arm model and use it's legacy interworking bitmap to support mix of old (without `endbr64`) and new binaries in task's address space, I see following problems: - It'll need support in kernel to prepare and manage readonly bitmap in task's address space. Along with code in kernel to support updating bitmap on `dlopen` happening in userspace. - Every indirect call to a legacy binary will lead to an additional load on legacy interworking bitmap virt memory and thus will lead to perf issues. So even in the case when someone has mix of old and new binaries, they most likely won't enable it. Or try to make sure that they have all binaries in task's address space with `endbr64` support. - As of today no one is using legacy interworking bitmap part of Intel CET. And I am also not sure how much of this hardware feature has been verified. So likely, you may run into issues and errata first. This is a lot of throwaway work to support a usecase which likely doesn't exist because most distros anyway compile binaries with `endbr64` and even if such a use case exist, its perf characteristics will suck quite bad and security guarantees are also poor (worst of both world). So my suggestion would be to keep it like shadow stack: Loader takes a decision whether to enable forward cfi for current task or not (like it is done for shadow stack) Hopefully Intel will deprecate legacy interworking part of Intel CET in future generation(s) and simplify it. > >> >> 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. > >During shadow stack/lam enabling we tried to create a generic x86 interface for >"per-thread features" with the idea that IBT would also go in there. However, >tglx made a bunch of points[0] against trying to do a universal thing. > >After that attempt we kind of gave up and just let them be specific. Although, >it was not appreciated at the time that arm and riscv shadow stack would be so >similar. > >I don't think we should have a generic "CFI" control though, because there are >other very different forms of backward edge CFI like PAC. > >[0] https://lore.kernel.org/lkml/87zgjjqico.ffs@tglx/ > >> >> 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. > >I think the situation for forward edge isn't the same as shadow stack, where the >features matched so well. At least for ARM. My best guess is that x86 could >possibly use it if/when we get to user IBT. But best guess, would have a PROT >involved too. So that could be different semantics. Sorry, I never looked at >your forward edge patches. I think you don't have a PROT, right? > >> >> If you agree, I'll let Paul choose the right name for it (given that indir_lp >> isn't a favorite) >