linux-kernel - Re: [PATCH 2/3] sparc: Add architecture support for clone3

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] [day] [month] [year] [list]

Message-ID: <e039b9f44b6856d1fd7173dcbdc1a24738ed6cfc.camel@physik.fu-berlin.de>
Date: Sun, 18 Jan 2026 15:39:27 +0100
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Jessica Clarke <jrtc27@...c27.com>, Ludwig Rydberg
	 <ludwig.rydberg@...sler.com>
Cc: davem@...emloft.net, andreas@...sler.com, brauner@...nel.org, 
	shuah@...nel.org, sparclinux@...r.kernel.org,
 linux-kselftest@...r.kernel.org, 	linux-kernel@...r.kernel.org,
 arnd@...db.de, geert@...ux-m68k.org, 	schuster.simon@...mens-energy.com
Subject: Re: [PATCH 2/3] sparc: Add architecture support for clone3

Hi,

On Sat, 2026-01-17 at 22:23 +0100, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> On Fri, 2026-01-16 at 16:47 +0000, Jessica Clarke wrote:
> > On Fri, Jan 16, 2026 at 04:30:50PM +0100, Ludwig Rydberg wrote:
> > > Add support for the clone3 system call to the SPARC architectures.
> > > 
> > > The implementation follows the pattern of the original clone syscall.
> > > However, instead of explicitly calling kernel_clone, the clone3
> > > handler calls the generic sys_clone3 handler in kernel/fork.
> > > In case no stack is provided, the parents stack is reused.
> > > 
> > > The return call conventions for clone on SPARC are kept for clone3:
> > >   Parent -->  %o0 == child's  pid, %o1 == 0
> > >   Child  -->  %o0 == parent's pid, %o1 == 1
> > 
> > One of the benefits of having a new clone3 is that the interface can be
> > made the same across all architectures*, unlike clone, which both passes
> > the arguments in different orders for different architectures and, in
> > the case of SPARC, has this weird return convention inherited from the
> > SunOS syscall interface. Is there a good reason to deviate for clone3
> > too and keep this annoying oddity going, that requires special-casing
> > SPARC when other architectures can just syscall(__NR_clone3, ...)?
> 
> Very good point. Since clone3() is a new syscall, I think it would make more
> sense to use the same interface as all the other architectures.
> 
> The weird syscall interface was already the reason why we had to write custom
> code for systemd on SPARC in order to use the raw clone() syscall.
> 
> I think the proposed implementation of clone3() for SPARC would actually break
> the libcamera build which calls clone3() using the syscall handler [1]:
> 
> FAILED: [code=1] src/libcamera/libcamera.so.0.6.0.p/process.cpp.o 
> c++ -Isrc/libcamera/libcamera.so.0.6.0.p -Isrc/libcamera -I../src/libcamera -Iinclude -I../include -Iinclude/libcamera -Iinclude/libcamera/ipa -Iinclude/libcamera/internal -Isrc/libcamera/proxy -
> I/usr/include/p11-kit-1 -I/usr/include/sparc64-linux-gnu -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -Wnon-virtual-dtor -
> Wno-redundant-move -Wmissing-declarations -Wshadow -include /build/reproducible-path/libcamera-0.6.0/obj-sparc64-linux-gnu/config.h -g -O2 -ffile-prefix-map=/build/reproducible-path/libcamera-0.6.0=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DLIBCAMERA_BASE_PRIVATE -MD -MQ src/libcamera/libcamera.so.0.6.0.p/process.cpp.o -MF
> src/libcamera/libcamera.so.0.6.0.p/process.cpp.o.d -o src/libcamera/libcamera.so.0.6.0.p/process.cpp.o -c ../src/libcamera/process.cpp
> ../src/libcamera/process.cpp: In member function ‘int libcamera::Process::start(const std::string&, libcamera::Span<const std::__cxx11::basic_string<char> >, libcamera::Span<const int>)’:
> ../src/libcamera/process.cpp:160:33: error: ‘SYS_clone3’ was not declared in this scope; did you mean ‘SYS_clone’?
>   160 |         long childPid = syscall(SYS_clone3, &cargs, sizeof(cargs));
>       |                                 ^~~~~~~~~~
>       |                                 SYS_clone
> 
> I'll verify that and report back.

I can confirm that libcamera builds fine and passes its testsuite with a patched kernel:

Ok:                38
Expected Fail:     1
Fail:              0
Skipped:           31

Full log written to /home/glaubitz/libcamera/libcamera-0.6.0/obj-sparc64-linux-gnu/meson-logs/testlog.txt
make[1]: Leaving directory '/home/glaubitz/libcamera/libcamera-0.6.0'

Whether the currently chosen interface is the right one, is another question though.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913