linux-kernel - Re: [PATCH v2 2/7] mips: fix mips_get_syscall

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2501141351140.50458@angie.orcam.me.uk>
Date: Tue, 14 Jan 2025 16:03:28 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Dmitry V. Levin" <ldv@...ace.io>
cc: Oleg Nesterov <oleg@...hat.com>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Eugene Syromyatnikov <evgsyr@...il.com>, 
    Mike Frysinger <vapier@...too.org>, Renzo Davoli <renzo@...unibo.it>, 
    Davide Berardi <berardi.dav@...il.com>, strace-devel@...ts.strace.io, 
    linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/7] mips: fix mips_get_syscall_arg() for O32 and
 N32

On Tue, 14 Jan 2025, Dmitry V. Levin wrote:

> >  How did you produce these results?
> 
> $ PATH="$HOME/x-tools/mips64-unknown-linux-gnu/bin:$PATH" make -j`nproc` ARCH=mips CROSS_COMPILE=mips64-unknown-linux-gnu- -C tools/testing/selftests TARGETS=ptrace USERLDFLAGS='-static' USERCFLAGS='-mabi=32'
> $ echo init |(cd tools/testing/selftests/ptrace && ln -snf get_syscall_info init && cpio --dereference -o -H newc -R 0:0) |gzip >get_syscall_info.mips-o32.img
> $ qemu-system-mips -nographic -kernel vmlinuz -initrd get_syscall_info.mips-o32.img -append 'console=ttyS0'
> 
> Likewise for mips64, but the patch for kselftest_harness.h from [1]
> is needed to see correct mismatch values in the test diagnostics.
> 
> [1] https://lore.kernel.org/all/20250108170757.GA6723@strace.io/

 Thanks, I'll try to see what's going on with `get_user'.

> >  The patch is definitely broken, the calling convention is the same 
> > between n32 and n64: 64-bit arguments in $4 through $11 registers as 
> > required, and your change makes n32 truncate arguments to 32 bits.
> 
> There must be something very specific to n32 then: apparently,
> __kernel_ulong_t is a 32-bit type on n32, so the syscall arguments are
> 32-bit values, at some point (in glibc?) they get sign-extended from 32 to
> 64 bits, and syscall_get_arguments returns them as 64-bit values different
> from the original syscall arguments, breaking the test.

 This matters at least for `lseek', which has an `off64_t' aka `long long' 
argument on n32 (there's no `_llseek' on n32).  Since arguments are passed 
via 64-bit registers and a `long long' datum is held in just one this is 
transparent between n32 and n64 (of course on n64 this corresponds to the 
plain `long' data type, so the kernel, which is always n64 for 64-bit 
configurations, sees the incoming argument as `long', and the same stands 
for the outgoing return value).

 Surely non-LFS lseek(2) will produce the syscall's `long long' argument 
truncated (cf. sysdeps/unix/sysv/linux/mips/mips64/n32/lseek.c in glibc), 
but both LFS lseek(2) and lseek64(2) will pass the native value on n32.

> If this is the expected behaviour, then I'd have to add an exception for
> mips n32 both to the kernel test and to strace that uses this interface.

 Is MIPS n32 the only psABI across all our architectures supported that 
can have `long long' syscall arguments?  I guess it might actually be the 
case, in which case I won't be surprised it needs specific handling.

  Maciej