Re: linux clone issue

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Oct 05, 2021 at 12:42:33AM -0400, Eric Hawicz wrote:
> 
> On 10/4/2021 10:33 AM, Manuel Bouyer wrote:
> > Hello
> > I'm trying to run a binary-only linux program under NetBSD 9.2.
> >  From what I found, the binary was built on Ubuntu 16.04
> > [...]
> > 
> > As you can see above (ktrace -si output), the read on fd 3 in 26751 returns
> > with an error as soon as the child does its execve(), just as if CLOSEEXEC
> > was set in the child. But the dup2(4,1) should keep the write side open
> > without CLOSEEXEC. The program does a similar sequence just before
> > (also forking a shell to execute some command) and it works.
> > Later when sh tries to write to stdout it gets a SIGPIPE.
> > 
> > I couldn't reproduce this with a simple program.
> > But it seems that I can't reproduce this clone call. It seems that we are
> > called with flags 0x1200011, which would translate to
> > CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID | SIGCHLD,
> > and a NULL stack pointer.
> > But when run on linux, this clone syscall straces to
> > CLONE_VM|CLONE_VFORK|SIGCHLD
> 
> I think that combination of flags is actually a "fork()" call, which glibc
> implements using clone.  I found that through https://eli.thegreenplace.net/2018/launching-linux-threads-and-processes-with-clone/,
> which mentions that glibc has a ARCH_FORK macro, though it seems that the
> more recent code uses an arch_fork inline function: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/arch-fork.h;h=b846da08f98839aef336868de24850626428509c;hb=HEAD

Yes, I think it's a form of fork() or vfork(). But when I compile a
test program on linux (RHEL7 or Ubuntu 20), fork() and vfork() appears
as fork and vfork in NetBSD's ktrace, not clone.

> 
> 
> > I tried writing a program using fork(), vfork() or clone() but
> > none of them would use the clone() syscall as do my linux binary.
> > Any idea what could cause clone() to be used this way ?
> 
> Is your binary statically linked?  Maybe it has a different glibc
> implementation from the .so that's on your system.

Yes, the linux emulation on NetBSD use suse's glibc, while my linux test
systems are RHEL7 and Ubuntu 20

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--