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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E79EBCAC5AE for ; Wed, 24 Sep 2025 21:41:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1F8D8E000D; Wed, 24 Sep 2025 17:41:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF6E48E000A; Wed, 24 Sep 2025 17:41:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0CFA8E000D; Wed, 24 Sep 2025 17:41:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BF1308E000A for ; Wed, 24 Sep 2025 17:41:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 36D6B1DCDDB for ; Wed, 24 Sep 2025 21:41:36 +0000 (UTC) X-FDA: 83925465792.03.B1D30DB Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by imf13.hostedemail.com (Postfix) with ESMTP id CC21A20005 for ; Wed, 24 Sep 2025 21:41:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=canonical.com header.s=20210705 header.b=NLKyQYaY; spf=pass (imf13.hostedemail.com: domain of heinrich.schuchardt@canonical.com designates 185.125.188.123 as permitted sender) smtp.mailfrom=heinrich.schuchardt@canonical.com; dmarc=pass (policy=none) header.from=canonical.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1758750094; 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=9pYJ1znLF25Yiw63WaSOuxWWlaoWjL/RNXrdeptb4BM=; b=gUgctPii07rcL0FnA47mw6IYjqFW+/7X4sJRwtP+ktvUi2hGgEAGbgS6Cx8CW25NDWA4DK NhX8rf8HFfq+hXII6zIq4L6sbtuGBA69vtMml8AWxEsxnw4ByQt6iVKq8ytBtAUGRyuNpg n8kbniP50g9Kukk9Y8jzFuu8r8ZedV8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1758750094; a=rsa-sha256; cv=none; b=yPA3lt3vMco3OtEB3zmPVbOGlGzvNtSLM4YmRGjibymj3hyfQ11pOaOXLAamz+H4cgzVV9 ku8zghTB0GR/BLP8gCAjlzYocd2hp3/A7WQh4/tWJw4pAbHDu+q2no1SJU/5KHNVjoebvj LuDfeWOoVHfGUUNoQQRcGR9DvuB+B18= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=canonical.com header.s=20210705 header.b=NLKyQYaY; spf=pass (imf13.hostedemail.com: domain of heinrich.schuchardt@canonical.com designates 185.125.188.123 as permitted sender) smtp.mailfrom=heinrich.schuchardt@canonical.com; dmarc=pass (policy=none) header.from=canonical.com Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id A7F583F949 for ; Wed, 24 Sep 2025 21:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1758750090; bh=9pYJ1znLF25Yiw63WaSOuxWWlaoWjL/RNXrdeptb4BM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NLKyQYaYNfCYJT91OfSF1Y229rMe/uZm/XM10jfRUhf0UVmJ7boKT3A3YQZ+R8U+i XLVWeDcP8M2nxwnyOUwiguP7bEW7p6JRiaWZRmyDg7+ORvxirzapHaNqGc0DVjE5Nh yHOTcGLYyB0l6B7NOX7+jl7/PkjDAYucmJydq/by+SlvosRhnTZ4xfBcpUOVfkWkUt W3sCKGpor7Chqq4gVc5C6zHoR+WPkoJZ3zTAiDjLSVFmTCUuk+4kccMX09dhBVBUgo HHElNFq3RftiuqPMl4ED48CCEKuUOESy5j10stMuGl0ElRN2S1BYfejAHitAzkQVVt d7vBhbqWAN7Xw== Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-244581ce13aso4315435ad.2 for ; Wed, 24 Sep 2025 14:41:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758750089; x=1759354889; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9pYJ1znLF25Yiw63WaSOuxWWlaoWjL/RNXrdeptb4BM=; b=vsavRfdGtJ8sLTL3KuKGnUnfmaFcTFHIsVKQEmlw04Hzbv0RJwgw7lP94bZpiQo/na 4pQn4wxOLGSbgEATQvcVlPBjie1AdgMil9c/cT9ttUKQh17wgoXytoaBU/ae8GsRdZUq 4qjJAcmAVXk9wcJXBjW11Vj4Qumcs7yflY4Ud/AAT8sFMAXN8ibbNrXZZ1xiRNak64zN 4vCve4PpPQ8t1cxvjudMxosdyo6NgUcbJWKo44WxQ1MSicFbzMUjqQH4+2qZgoG7kg+q l8tBta3EScBQaWlZDoWjpWC8Su3zFVVsjb6YKwoeT4Mu9t52uhdIfJLoABXPiICiPG57 8xoA== X-Forwarded-Encrypted: i=1; AJvYcCVMcDD4FIrI7g/dmS9St+B/pt5FAziKRlsZHBOThC0/q3jhkq4JuTj0tBtBAz9RibNyMauzMWVK2A==@kvack.org X-Gm-Message-State: AOJu0YxeZLS+MQPOsKSh2wIfmzaZfCTw65zg/8c0wovYhycm+hyRQvZL SGOhaSzzYRaRGgmou2J1rozqtjAyLjZ5BfrQV4dQcm4Gn/NbuLCcpB2g2rr2mKZw6ivK3AtaMUs xofqvc4VP2wqWblRhY2vbbvs0+aL3Ap8Mg6GgxnpVXO+CYETATIk226n2iuxgKrKbrYZOS3tJLo 6iIbXL4ZEf/TUDqqR24wMn72tor9SxEU/hpLnuJduej3s= X-Gm-Gg: ASbGnctDGBaKC6jAFumW/gmnEKjfxhLvwI1rbRkoHc19MRWMU53iBX8yewzOi9/no+U bD11bOItY9eO2byuR4m1zA67G5W/ObHf33Bvma/ucoY+h3Tv0/5uA6/pFn8x1WDCskq2GmC/gX2 ABV61k9As2cHalhL9yLQ== X-Received: by 2002:a17:903:37c3:b0:272:8c5f:1325 with SMTP id d9443c01a7336-27ed4a30cfemr12877565ad.36.1758750089068; Wed, 24 Sep 2025 14:41:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGit+7xVZf41CcHGBbQtvgPbP5bLRU4Ex5Im8B0jVLwSOhCxir7WNv2DuuLLTQCPZQ4MogXzP/zY+E2B6qUP0g= X-Received: by 2002:a17:903:37c3:b0:272:8c5f:1325 with SMTP id d9443c01a7336-27ed4a30cfemr12876725ad.36.1758750088373; Wed, 24 Sep 2025 14:41:28 -0700 (PDT) MIME-Version: 1.0 References: <20250731-v5_user_cfi_series-v19-0-09b468d7beab@rivosinc.com> In-Reply-To: From: Heinrich Schuchardt Date: Wed, 24 Sep 2025 23:41:17 +0200 X-Gm-Features: AS18NWBe4nV5wxYipXcIJasE75xDEqfNOUdLCNPKE3zqJAjrvNelbkpgKW9XgCM Message-ID: Subject: Re: [PATCH v19 00/27] riscv control-flow integrity for usermode To: Deepak Gupta Cc: Paul Walmsley , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , Paul Walmsley , Palmer Dabbelt , Albert Ou , Conor Dooley , Rob Herring , Krzysztof Kozlowski , Arnd Bergmann , Christian Brauner , Peter Zijlstra , Oleg Nesterov , Eric Biederman , Kees Cook , Jonathan Corbet , Shuah Khan , Jann Horn , Conor Dooley , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl , Trevor Gross , Benno Lossin , linux-kernel , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-riscv , devicetree , linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Alistair Francis , Richard Henderson , jim.shu@sifive.com, Andy Chiu , Kito Cheng , Charlie Jenkins , Atish Patra , Evan Green , =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Alexandre Ghiti , samitolvanen@google.com, Mark Brown , rick.p.edgecombe@intel.com, rust-for-linux@vger.kernel.org, Zong Li , David Hildenbrand , Florian Weimer , bharrington@redhat.com, Aurelien Jarno Content-Type: multipart/alternative; boundary="000000000000443e44063f92ea00" X-Stat-Signature: gaepeiznogn39usjef53j44iyx643nfp X-Rspam-User: X-Rspamd-Queue-Id: CC21A20005 X-Rspamd-Server: rspam10 X-HE-Tag: 1758750093-771875 X-HE-Meta: U2FsdGVkX181u0NdQ43h0djbLAWJ6MAar4U33RX0SlfLUM09kmAeobyX39ZmiAmET6iPFxvuVBMTlkxXN2AQcCf3h429Zb3DybzjFjEJBrNMRZ1WKG6J58mTjGjNP5qNCk6o3EyYmRQ0ojgq3qYyFe1Z1iwgiuHuB6QYVPASCTk95FOAu4w82qvtxD5JmVAWPZKTUGF7DpcMvr9vtG25PI2AU1iNfGJx7DCXa8PyH4qX3XB4g8QLvNvP8Z9hIgXoC+z8jAkuS90qaQ/HNDEey4cK7ZHumc2Btd7+Ki+Eg29n60bVyDy939nVc/7LVbPVWMByolKYUuAWemeyw/0Pq47JLRorGej3O8UGKUk72xxUStI61K1MxpAvJbJpKldWe5pEvyTwpUkddkonNprKoJS4/uofUuKhynvrAlvWWqYIJXju6ktMYXzUJC63LbizQ7mkk+2qm1ZbCp+U8EP+uVacxJvSaotjOFa7Z8CCUnHehr81RUpVQnp8ByFjMZOP4yUV2B/6O5GrwP2ijR5sCryI5OYydUA6Z/AA6lOB3Ek7vBkNYpHiFSwQMrsyfQzr5hVL++JOE0sS+n5EGZCaLF/laVHmxDLSsF93ahhZfv01D+c7Z13Eql6pe52R6EMuOIjZ18DPqolUV804cZzSwp7X69JQalKpTj8/Pgc5aUUE1H881EUG/73JNTNu8Cz2sQd1MHjry4TiGLeaK+RMvQtKl6dhVTkTIIzHePn/qWclMjFXRh9zKeMvqdHSZhGo+1B0kiN8imk3AgLIInuKiB7cEEygXLnMQz2JiSN1zIo00BvxsNMy1oVjG/zXSmJuagX2RkjuKT160uKtjcwTkx2iaXXFFFJ/gJ21qZoVZFu9B8wSrm01eAxIn/pvTAfIIrkiKwAj3c/WjzEa0jk2n2XVVjXCo/FDoa/Eq24ajaoF/Ei9smzCbo8DigYKp1KBGjqMDJs0OhZMSzdWRtv 3bv7nJPb tgQFgmC9Y95AZtz5dm6vqUmBDpQSLod10UnTYMQSKdNbzrV3hbU340Dk/NQsMcPCIEvzgkWzO+OCtLF8euMXJIfVd+FBjVHFUKgUrdDdRducXflNKnCCC7zjkJnN78d81OoKeKVI5MYYJXVeabY3GqKetcIoA2iaknZZX4c4WlGe9ZRE4/2mPjIkx6m3WrjEYYdoYKlAqvzFB/bOcbuog++mHLPySKUoR+795c4jR7Zgt9yw60ELyMn5SsPCQXX6O2SNm22CSZfvIBb0cqZSd9RpWsITh2RRpOLkb45DBw6K3AvLIL+qHDwVSdZvwANfUjSBCGyhFLrjH4M9WSUMI+UM9eb0luvbBfGW6XpRQVIG0NuPdrmrLKmEH8gns4CPRKTZCCu1Cf1F4/Lx8jpddA4h8fTewhWfsL8QNFr/wVC4rI8yTxJnc901J+2tn3nHAOdyUGEVakftXdDPC4L7Fiew9mkX42jbzW1RH7bSQYNXVYnSONrgYZXbuEv/pxRLwaaHE 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: --000000000000443e44063f92ea00 Content-Type: text/plain; charset="UTF-8" Deepak Gupta schrieb am Mi., 24. Sept. 2025, 20:40: > On Wed, Sep 24, 2025 at 08:36:11AM -0600, Paul Walmsley wrote: > >Hi, > > > >On Thu, 31 Jul 2025, Deepak Gupta wrote: > > > >[ ... ] > > > >> vDSO related Opens (in the flux) > >> ================================= > >> > >> I am listing these opens for laying out plan and what to expect in > future > >> patch sets. And of course for the sake of discussion. > >> > > > >[ ... ] > > > >> How many vDSOs > >> --------------- > >> Shadow stack instructions are carved out of zimop (may be operations) > and if CPU > >> doesn't implement zimop, they're illegal instructions. Kernel could be > running on > >> a CPU which may or may not implement zimop. And thus kernel will have > to carry 2 > >> different vDSOs and expose the appropriate one depending on whether CPU > implements > >> zimop or not. > > > >If we merge this series without this, then when CFI is enabled in the > >Kconfig, we'll wind up with a non-portable kernel that won't run on older > >hardware. We go to great lengths to enable kernel binary portability > >across the presence or absence of other RISC-V extensions, and I think > >these CFI extensions should be no different. > > > >So before considering this for merging, I'd like to see at least an > >attempt to implement the dual-vDSO approach (or something equivalent) > >where the same kernel binary with CFI enabled can run on both pre-Zimop > >and post-Zimop hardware, with the existing userspaces that are common > >today. > > Added some distro folks in this email chain. > > After patchwork meeting today, I wanted to continue discussion here. So > thanks > Paul for looking into it and initiating a discussion here. > > This patch series has been in the queue for quite a long time and we have > had > deliberations on vDSO topic earlier as well and after those deliberations > it > was decided to go ahead with merge and it indeed was sent for 6.17 merge > window. Unfortunatley due to other unforeseen reasons, entirety of riscv > changes were not picked. So it's a bit disappointing to see back-paddling > on > this topic. > > Anyways, we are here. So I'll provide a bit of context for the list about > deliberations and discussions we have been having for so many merge > windows. > This so that a holistic discussion can happen on this before we make a > decision. > > Issue > ====== > > Instructions in RISC-V shadow stack extension (zicfiss - [1]) are carved > out of > "may be ops" aka zimop extension [2]. "may be ops" are illegal on non-RVA23 > hardware. This means any existing riscv CPU or future CPU which isn't RVA23 > compliant and not implementing zimop will treat these encodings as illegal. > > Current kernel patches enable shadow stack and landing pad support for > userspace using config `CONFIG_RISCV_USER_CFI`. If this config is selected > then > vDSO that will be exposed to user space will also have shadow stack > instructions in them. Kernel compiled with `CONFIG_RISCV_USER_CFI`, for > sake of > this discussion lets call it RVA23 compiled kernel. > > Issue that we discussed earlier and even today is "This RVA23 compiled > kernel > won't be able to support non-RVA23 userspace on non-RVA23 hardware > because". > Please note that issue exists only on non-RVA23 hardware (which is existing > hardware and future hardware which is not implementing zimop). RVA23 > compiled > kernel can support any sort of userspace on RVA23 hardware. > > > Discussion > =========== > > So the issue is not really shadow stack instructions but rather may be op > instructions in codegen (binaries and vDSO) which aren't hidden behind any > flag (to hide them if hardware doesn't support). And if I can narrow down > further, primary issue we are discussing is that if cfi is enabled during > kernel compile, it is bringing in a piece of code (vDSO) which won't work > on existing hardware. But the counter point is if someone were to deploy > RVA23 compiled kernel on non-RVA23 hardware, they must have compiled > rest of the userspace without shadow stack instructions in them for such > a hardware. And thus at this point they could simply choose *not* to turn > on > `CONFIG_RISCV_USER_CFI` when compiling such kernel. It's not that > difficult to > do so. > > Any distro who is shipping userspace (which all of them are) along with > kernel > will not be shipping two different userspaces (one with shadow stack and > one > without them). If distro are shipping two different userspaces, then they > might > as well ship two different kernels. Tagging some distro folks here to get > their > take on shipping different userspace depending on whether hardware is > RVA23 or > not. @Heinrich, @Florian, @redbeard and @Aurelien. > Ubuntu like other non-rolling distros maintains separate kernels per release. Even if a kernel is backported there will be differences in applied patches and configuration between the distro releases. Looking at the userspace I don't see how we could have a CFI enabled distro that would run on hardware without support for maybe operations. Without CFI userland I cannot see a use case for a CFI enabled kernel for such hardware either. We cannot expect the whole software ecosystem including containers to switch to CFI synchronously. Hence software that is compiled without CFI must be able call into a CFI enabled kernel and its vDSO library. Best regards Heinrich > Major distro's have already drawn a distinction here that they will drop > support for hardware which isn't RVA23 for the sake of keeping binary > distribution simple. > > Only other use case that was discussed of a powerful linux user who just > wants > to use a single kernel on all kinds of riscv hardware. I am imagining such > a > user knows enough about kernel and if is really dear to them, they can > develop > their own patches and send it upstream to support their own usecase and we > can > discuss them out. Current patchset don't prevent such a developer to send > such > patches upstream. > > I heard the argument in meeting today that "Zbb" enabling works similar for > kernel today. I looked at "Zbb" enabling. It's for kernel usage and it's > surgically placed in kernel using asm hidden behind alternatives. vDSO > isn't > compiled with Zbb. Shadow stack instructions are part of codegen for C > files > compiled into vDSO. > > Furthermore, > > Kernel control flow integrity will introduce shadow stack instructions all > over the kernel binary. Such kernel won't be deployable on non-RVA23 > hardware. > How to deal with this problem for a savvy kernel developer who wants to run > same cfi enabled kernel binary on multiple hardware? > > Coming from engineering and hacker point of view, I understand the desire > here > but I still see that it's complexity enforced on rest of the kernel from a > user > base which anyways can achieve such goals. For majority of usecases, I > don't > see a reason to increase complexity in the kernel for build, possibly > runtime > patching and thus possibly introduce more issues and errors just for the > sake > of a science project. > > Being said that, re-iterating that currently default for > `CONFIG_RISCV_USER_CFI` > is "n" which means it won't be breaking anything unless a user opts "Y". > So even > though I really don't see a reason and usability to have complexity in > kernel to > carry multiple vDSOs, current patchsets are not a hinderance for such > future > capability (because current default is No) and motivated developer is > welcome > to build on top of it. Bottomline is I don't see a reason to block current > patchset from merging in v6.18. > > > [1] - > https://github.com/riscv/riscv-isa-manual/blob/main/src/unpriv-cfi.adoc#shadow-stack-zicfiss > [2] - https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc > > > > >thanks Deepak, > > > >- Paul > --000000000000443e44063f92ea00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Deepak Gupta <debug@rivosinc.com> schrieb am Mi., 24. Sept.= 2025, 20:40:
On Wed, Sep 24, 2025 = at 08:36:11AM -0600, Paul Walmsley wrote:
>Hi,
>
>On Thu, 31 Jul 2025, Deepak Gupta wrote:
>
>[ ... ]
>
>> vDSO related Opens (in the flux)
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> I am listing these opens for laying out plan and what to expect in= future
>> patch sets. And of course for the sake of discussion.
>>
>
>[ ... ]
>
>> How many vDSOs
>> ---------------
>> Shadow stack instructions are carved out of zimop (may be operatio= ns) and if CPU
>> doesn't implement zimop, they're illegal instructions. Ker= nel could be running on
>> a CPU which may or may not implement zimop. And thus kernel will h= ave to carry 2
>> different vDSOs and expose the appropriate one depending on whethe= r CPU implements
>> zimop or not.
>
>If we merge this series without this, then when CFI is enabled in the >Kconfig, we'll wind up with a non-portable kernel that won't ru= n on older
>hardware.=C2=A0 We go to great lengths to enable kernel binary portabil= ity
>across the presence or absence of other RISC-V extensions, and I think<= br> >these CFI extensions should be no different.
>
>So before considering this for merging, I'd like to see at least an=
>attempt to implement the dual-vDSO approach (or something equivalent) >where the same kernel binary with CFI enabled can run on both pre-Zimop=
>and post-Zimop hardware, with the existing userspaces that are common >today.

Added some distro folks in this email chain.

After patchwork meeting today, I wanted to continue discussion here. So tha= nks
Paul for looking into it and initiating a discussion here.

This patch series has been in the queue for quite a long time and we have h= ad
deliberations on vDSO topic earlier as well and after those deliberations i= t
was decided to go ahead with merge and it indeed was sent for 6.17 merge window. Unfortunatley due to other unforeseen reasons, entirety of riscv changes were not picked. So it's a bit disappointing to see back-paddli= ng on
this topic.

Anyways, we are here. So I'll provide a bit of context for the list abo= ut
deliberations and discussions we have been having for so many merge windows= .
This so that a holistic discussion can happen on this before we make a
decision.

Issue
=3D=3D=3D=3D=3D=3D

Instructions in RISC-V shadow stack extension (zicfiss - [1]) are carved ou= t of
"may be ops" aka zimop extension [2]. "may be ops" are = illegal on non-RVA23
hardware. This means any existing riscv CPU or future CPU which isn't R= VA23
compliant and not implementing zimop will treat these encodings as illegal.=

Current kernel patches enable shadow stack and landing pad support for
userspace using config `CONFIG_RISCV_USER_CFI`. If this config is selected = then
vDSO that will be exposed to user space will also have shadow stack
instructions in them. Kernel compiled with `CONFIG_RISCV_USER_CFI`, for sak= e of
this discussion lets call it RVA23 compiled kernel.

Issue that we discussed earlier and even today is "This RVA23 compiled= kernel
won't be able to support non-RVA23 userspace on non-RVA23 hardware beca= use".
Please note that issue exists only on non-RVA23 hardware (which is existing=
hardware and future hardware which is not implementing zimop). RVA23 compil= ed
kernel can support any sort of userspace on RVA23 hardware.


Discussion
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So the issue is not really shadow stack instructions but rather may be op instructions in codegen (binaries and vDSO) which aren't hidden behind = any
flag (to hide them if hardware doesn't support). And if I can narrow do= wn
further, primary issue we are discussing is that if cfi is enabled during kernel compile, it is bringing in a piece of code (vDSO) which won't wo= rk
on existing hardware. But the counter point is if someone were to deploy RVA23 compiled kernel on non-RVA23 hardware, they must have compiled
rest of the userspace without shadow stack instructions in them for such a hardware. And thus at this point they could simply choose *not* to turn o= n
`CONFIG_RISCV_USER_CFI` when compiling such kernel. It's not that diffi= cult to
do so.

Any distro who is shipping userspace (which all of them are) along with ker= nel
will not be shipping two different userspaces (one with shadow stack and on= e
without them). If distro are shipping two different userspaces, then they m= ight
as well ship two different kernels. Tagging some distro folks here to get t= heir
take on shipping different userspace depending on whether hardware is RVA23= or
not. @Heinrich, @Florian, @redbeard and @Aurelien.

Ubuntu like other non-rol= ling distros maintains separate kernels per release. Even if a kernel is ba= ckported there will be differences in applied patches and configuration bet= ween the distro releases.

Looking at the userspace I don't see how we could have a CFI enabled = distro that would run on hardware without support for maybe operations. Wit= hout CFI userland I cannot see a use case for a CFI enabled kernel for such= hardware either.

We can= not expect the whole software ecosystem including containers to switch to C= FI synchronously. Hence software that is compiled without CFI must be able = call into a CFI enabled kernel and its vDSO library.

Best regards

=
Heinrich


Major distro's have already drawn a distinction here that they will dro= p
support for hardware which isn't RVA23 for the sake of keeping binary distribution simple.

Only other use case that was discussed of a powerful linux user who just wa= nts
to use a single kernel on all kinds of riscv hardware. I am imagining such = a
user knows enough about kernel and if is really dear to them, they can deve= lop
their own patches and send it upstream to support their own usecase and we = can
discuss them out. Current patchset don't prevent such a developer to se= nd such
patches upstream.

I heard the argument in meeting today that "Zbb" enabling works s= imilar for
kernel today. I looked at "Zbb" enabling. It's for kernel usa= ge and it's
surgically placed in kernel using asm hidden behind alternatives. vDSO isn&= #39;t
compiled with Zbb. Shadow stack instructions are part of codegen for C file= s
compiled into vDSO.

Furthermore,

Kernel control flow integrity will introduce shadow stack instructions all<= br> over the kernel binary. Such kernel won't be deployable on non-RVA23 ha= rdware.
How to deal with this problem for a savvy kernel developer who wants to run=
same cfi enabled kernel binary on multiple hardware?

Coming from engineering and hacker point of view, I understand the desire h= ere
but I still see that it's complexity enforced on rest of the kernel fro= m a user
base which anyways can achieve such goals. For majority of usecases, I don&= #39;t
see a reason to increase complexity in the kernel for build, possibly runti= me
patching and thus possibly introduce more issues and errors just for the sa= ke
of a science project.

Being said that, re-iterating that currently default for `CONFIG_RISCV_USER= _CFI`
is "n" which means it won't be breaking anything unless a use= r opts "Y". So even
though I really don't see a reason and usability to have complexity in = kernel to
carry multiple vDSOs, current patchsets are not a hinderance for such futur= e
capability (because current default is No) and motivated developer is welco= me
to build on top of it. Bottomline is I don't see a reason to block curr= ent
patchset from merging in v6.18.


[1] - https://github.com/riscv/riscv-isa-manual/blob/main/src/unpriv-cfi= .adoc#shadow-stack-zicfiss
[2] - https://github.co= m/riscv/riscv-isa-manual/blob/main/src/zimop.adoc

>
>thanks Deepak,
>
>- Paul
--000000000000443e44063f92ea00--