linux-kernel - Re: [PATCH 0/3] LoongArch: initial 32-bit UAPI

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: <1def7604-634d-4dd9-a8c3-7168409a72cf@app.fastmail.com>
Date: Sun, 05 Jan 2025 05:43:14 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jiaxun Yang" <jiaxun.yang@...goat.com>, "Xi Ruoyao" <xry111@...111.site>,
 "Huacai Chen" <chenhuacai@...nel.org>, "WANG Xuerui" <kernel@...0n.name>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
 Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 0/3] LoongArch: initial 32-bit UAPI

On Sat, Jan 4, 2025, at 17:03, Jiaxun Yang wrote:
> 在2025年1月4日一月 下午3:13，Xi Ruoyao写道：
>>
>>> We need to be careful in defining the ABI to ensure that this covers
>>> all the corner cases, such as defining a signal stack layout with
>>> room to save 64-bit user register contents if there is a chance that
>>> a 32-bit userspace will end up using the wide registers when
>>> running on a 64-bit kernel, but also avoid any dependency on 64-bit
>>> registers in the ABI itself.
>>
>> Yes such issues are nasty, we'd already need something in the calling
>> convention like "on 64-bit hardware, in ILP32 ABI the saved registers
>> may be unchanged or changed to the sign-extension from the lower 32 bits
>> of the original value."
>
> Makes sense to me. For MIPS the n32 (ILP32 for 64bit) ABI has a new set of
> UAPI definition (also mandate 64bit GPR). While the vanilla o32 ABI is 32bit
> only, which disallows any 64bit instruction in user space.
>
> When I'm designing current LA32 ABI I actually have o32 ABI in mind. However
> LoongArch64 hardware is not capable to disable 32bit instructions alone. So
> if we end up doing something like o32 the limitation of 32bit instruction needs
> to be enforced at compiler side.

> So I think the question would do we want to allow 64bit instructions for
> LoongArch's ILP32 kernel UAPI. We can either go through MIPS's o32 PATH,
> making 32bit ABI truly 32bit, or maybe reusing the UAPI for ILP32 on 64.

If at all possible, I think both the kernel's UAPI and the user side
ELF psABI should be defined as compatible with 32-bit hardware and
with userspace running on 64-bit kernels.

> From Guo Ren's RISC-V's compat work and arm64ilp32 I can certainly see
> the benefit of ILP32 on 64. Maybe we can bring that to LoongArch as well.

I would not take these as examples, since something went wrong for
each of them:

- RISC-V defined rv64 to not be a superset of rv32, so arithmetic
  instructions behave differently unless you switch modes
- aarch64 and aarch32 modes are completely different instruction sets,
  so aarch64ilp32 is by definition incompatible
- mips o32 as I understand it could work with 64-bit at the ISA level,
  as n32 does, but the ELF ABI does not allow using 64-bit registers,
  while n32 requires the use of 64-bit registers and does not work
  on 32-bit hardware.

If both the ISA and the ABI get it right, it should be possible to
build 32-bit userspace that is compatible with both when targeting
a 32-bit hardware, but still use 64-bit registers inside a single
function when the compiler is building for a 64-bit capable CPU
(e.g. "-march=la464 -m32"). There is a small cost in the calling
conventions for passing u64 arguments in pairs of registers
(unlike n32/x32/aarch64ilp32/rv64ilp32), but a huge benefit in
not maintaining two incompatible ABIs.

     Arnd