lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mhng-e8248074-b79c-42f6-986f-9993851b6be2@palmer-ri-x1c9a>
Date: Thu, 27 Mar 2025 09:20:09 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: Liam.Howlett@...cle.com
CC: david@...hat.com, peterz@...radead.org, guoren@...nel.org,
  Arnd Bergmann <arnd@...db.de>, Greg KH <gregkh@...uxfoundation.org>,
  Linus Torvalds <torvalds@...ux-foundation.org>, Paul Walmsley <paul.walmsley@...ive.com>, anup@...infault.org,
  atishp@...shpatra.org, oleg@...hat.com, kees@...nel.org, tglx@...utronix.de,
  Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>, brauner@...nel.org,
  akpm@...ux-foundation.org, rostedt@...dmis.org, edumazet@...gle.com, unicorn_wang@...look.com,
  inochiama@...look.com, gaohan@...as.ac.cn, shihua@...as.ac.cn, jiawei@...as.ac.cn,
  wuwei2016@...as.ac.cn, drew@...7.com, prabhakar.mahadev-lad.rj@...renesas.com, ctsai390@...estech.com,
  wefu@...hat.com, kuba@...nel.org, pabeni@...hat.com, josef@...icpanda.com, dsterba@...e.com,
  mingo@...hat.com, boqun.feng@...il.com, xiao.w.wang@...el.com, qingfang.deng@...lower.com.cn,
  leobras@...hat.com, jszhang@...nel.org, Conor Dooley <conor.dooley@...rochip.com>,
  samuel.holland@...ive.com, yongxuan.wang@...ive.com, luxu.kernel@...edance.com, ruanjinjie@...wei.com,
  cuiyunhui@...edance.com, wangkefeng.wang@...wei.com, qiaozhe@...as.ac.cn,
  Ard Biesheuvel <ardb@...nel.org>, ast@...nel.org, linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
  kvm@...r.kernel.org, kvm-riscv@...ts.infradead.org, linux-mm@...ck.org,
  linux-crypto@...r.kernel.org, bpf@...r.kernel.org, linux-input@...r.kernel.org,
  linux-perf-users@...r.kernel.org, linux-serial@...r.kernel.org, linux-fsdevel@...r.kernel.org,
  linux-arch@...r.kernel.org, maple-tree@...ts.infradead.org, linux-trace-kernel@...r.kernel.org,
  netdev@...r.kernel.org, linux-atm-general@...ts.sourceforge.net, linux-btrfs@...r.kernel.org,
  netfilter-devel@...r.kernel.org, coreteam@...filter.org, linux-nfs@...r.kernel.org, linux-sctp@...r.kernel.org,
  linux-usb@...r.kernel.org, linux-media@...r.kernel.org
Subject:     Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI

On Tue, 25 Mar 2025 12:23:39 PDT (-0700), Liam.Howlett@...cle.com wrote:
> * David Hildenbrand <david@...hat.com> [250325 14:52]:
>> On 25.03.25 13:26, Peter Zijlstra wrote:
>> > On Tue, Mar 25, 2025 at 08:15:41AM -0400, guoren@...nel.org wrote:
>> > > From: "Guo Ren (Alibaba DAMO Academy)" <guoren@...nel.org>
>> > >
>> > > Since 2001, the CONFIG_64BIT kernel has been built with the LP64 ABI,
>> > > but this patchset allows the CONFIG_64BIT kernel to use an ILP32 ABI
>> >
>> > I'm thinking you're going to be finding a metric ton of assumptions
>> > about 'unsigned long' being 64bit when 64BIT=y throughout the kernel.
>> >
>> > I know of a couple of places where 64BIT will result in different math
>> > such that a 32bit 'unsigned long' will trivially overflow.

Ya, I write code that assumes "unsigned long" is the size of a register 
pretty regularly.

>> >
>> > Please, don't do this. This adds a significant maintenance burden on all
>> > of us.
>> >
>>
>> Fully agreed.
>
> I would go further and say I do not want this to go in.

Seems reasonable to me, and I think it's also been the general sentiment 
when this stuff comes up.  This specific implementation seems 
particularly clunky, but I agree that it's going to be painful to do 
this sort of thing.

> The open ended maintenance burden is not worth extending hardware life
> of a board with 16mb of ram (If I understand your 2023 LPC slides
> correctly).

We can already run full 32-bit kernels on 64-bit hardware.  The hardware 
needs to support configurable XLEN, but there's systems out there that 
do already.

It's not like any of the existing RISC-V stuff ships in meaningful 
volumes.  So I think it's fine to just say that vendors who want tiny 
memories should build hardware that plays nice with those constraints, 
and vendors who build hardware that doesn't make any sense get to pick 
up the pieces.

I get RISC-V is where people go to have crazy ideas, but there's got to 
be a line somewhere...

>
> Thank you,
> Liam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ