Message-ID: <lhuldlwgpij.fsf@oldenburg.str.redhat.com>
Date: Tue, 30 Sep 2025 13:15:32 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Deepak Gupta <debug@...osinc.com>
Cc: Paul Walmsley <pjw@...nel.org>,  Thomas Gleixner <tglx@...utronix.de>,
  Ingo Molnar <mingo@...hat.com>,  Borislav Petkov <bp@...en8.de>,  Dave
 Hansen <dave.hansen@...ux.intel.com>,  x86@...nel.org,  "H. Peter Anvin"
 <hpa@...or.com>,  Andrew Morton <akpm@...ux-foundation.org>,  "Liam R.
 Howlett" <Liam.Howlett@...cle.com>,  Vlastimil Babka <vbabka@...e.cz>,
  Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,  Paul Walmsley
 <paul.walmsley@...ive.com>,  Palmer Dabbelt <palmer@...belt.com>,  Albert
 Ou <aou@...s.berkeley.edu>,  Conor Dooley <conor@...nel.org>,  Rob Herring
 <robh@...nel.org>,  Krzysztof Kozlowski <krzk+dt@...nel.org>,  Arnd
 Bergmann <arnd@...db.de>,  Christian Brauner <brauner@...nel.org>,  Peter
 Zijlstra <peterz@...radead.org>,  Oleg Nesterov <oleg@...hat.com>,  Eric
 Biederman <ebiederm@...ssion.com>,  Kees Cook <kees@...nel.org>,  Jonathan
 Corbet <corbet@....net>,  Shuah Khan <shuah@...nel.org>,  Jann Horn
 <jannh@...gle.com>,  Conor Dooley <conor+dt@...nel.org>,  Miguel Ojeda
 <ojeda@...nel.org>,  Alex Gaynor <alex.gaynor@...il.com>,  Boqun Feng
 <boqun.feng@...il.com>,  Gary Guo <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  Andreas Hindborg <a.hindborg@...nel.org>,
  Alice Ryhl <aliceryhl@...gle.com>,  Trevor Gross <tmgross@...ch.edu>,
  Benno Lossin <lossin@...nel.org>,  linux-kernel@...r.kernel.org,
  linux-fsdevel@...r.kernel.org,  linux-mm@...ck.org,
  linux-riscv@...ts.infradead.org,  devicetree@...r.kernel.org,
  linux-arch@...r.kernel.org,  linux-doc@...r.kernel.org,
  linux-kselftest@...r.kernel.org,  alistair.francis@....com,
  richard.henderson@...aro.org,  jim.shu@...ive.com,  Andy Chiu
 <andybnac@...il.com>,  kito.cheng@...ive.com,  charlie@...osinc.com,
  atishp@...osinc.com,  evan@...osinc.com,  cleger@...osinc.com,
  alexghiti@...osinc.com,  samitolvanen@...gle.com,  broonie@...nel.org,
  rick.p.edgecombe@...el.com,  rust-for-linux@...r.kernel.org,  Zong Li
 <zong.li@...ive.com>,  David Hildenbrand <david@...hat.com>,  Heinrich
 Schuchardt <heinrich.schuchardt@...onical.com>,  bharrington@...hat.com,
  Aurelien Jarno <aurel32@...ian.org>, bergner@...storrent.com,
 jeffreyalaw@...il.com
Subject: Re: [PATCH v19 00/27] riscv control-flow integrity for usermode

* Deepak Gupta:

> 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.
>
> 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.

The following are just my personal thoughts.

For commercial distributions, I just don't see how things work out if
you have hardware that costs less than (say) $30 over its lifetime, and
you want LTS support for 10+ years.  The existing distribution business
models aren't really compatible with such low per-node costs.  So it
makes absolute sense for distributions to target more powerful cores,
and therefore require RVA23.  Nobody is suggesting that mainstream
distributions should target soft-float, either.

For community distributions, it is a much tougher call.  Obsoleting
virtually all existing hardware sends a terrible signal to early
supporters of the architecture.  But given how limited the RISC-V
baseline ISA is, I'm not sure if there is much of a choice here.  Maybe
it's possible to soften the blow by committing to (say) two more years
of baseline ISA support, and then making the switch, assuming that RVA23
hardware for local installation is widely available by then.

However, my real worry is that in the not-too-distant future, another
ISA transition will be required after RVA23.  This is not entirely
hypothetical because RVA23 is still an ISA designed mostly for C (at
least in the scalar space, I don't know much about the vector side).
Other architectures carry forward support for efficient overflow
checking (as required by Ada and some other now less-popular languages,
and as needed for efficiently implementing fixnums with arbitrary
precision fallback).  Considering current industry trends, it is not
inconceivable that these ISA features become important again in the near
term.

You can see the effect of native overflow checking support if you look
at Ada code examples with integer arithmetic.  For example, this:

function Fib (N: Integer) return Integer is
begin
   if N <= 1 then
      return N;
   else
      return Fib (N - 1) + Fib (N - 2);
   end if;
end;

produces about 370 RISC-V instructions with -gnato, compared to 218
instructions with -gnato0 and overflow checking disabled (using GCC
trunk).  For GCC 15, the respective instruction counts are 301 and 258
for x86-64, and 288 and 244 for AArch64.  RVA23 reduces the instruction
count with overflow checking to 353.  A further reduction should be
possible once GCC starts using xnor in its overflow checks, but I expect
that the overhead from overflow checking will remain high.

Thanks,
Florian

Powered by blists - more mailing lists