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: <2c46fc29-d24b-40b9-a64b-081a1f2a7a25@app.fastmail.com>
Date: Sat, 04 Jan 2025 16:03:29 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Xi Ruoyao" <xry111@...111.site>, "Arnd Bergmann" <arnd@...db.de>,
 "Huacai Chen" <chenhuacai@...nel.org>, "Xuerui Wang" <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

在2025年1月4日一月 下午3:13，Xi Ruoyao写道：
[...]
>> 
>> I assume the MIPS legacy means that a 64-bit kernel is going to be
>> able to run the same ILP32 binaries as a 32-bit kernel running on
>> pure 32-bit hardware, similar to powerpc/s390/x86, but unlike
>> riscv/arm?
>
> LoongArch has instructions like addi.d/addi.w, instead of addi/addi.w,
> thus on 32-bit implementation it's simply addi.d is missing, not the
> semantic of addi is changed.  So I cannot see a real reason we cannot
> support the same ILP32 userspace binaries compiled for 32-bit hardware
> on 64-bit hardware.

The only concern is the behaviour of PC relative instructions will change
in VA32 mode for LoongArch64 systems, i.e. address will be signed extended.
However I think this serves ILP32 purpose well.

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

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

Thanks 

>
> -- 
> Xi Ruoyao <xry111@...111.site>
> School of Aerospace Science and Technology, Xidian University

-- 
- Jiaxun