Incorrect sys_clone() arguments on ARM? about bubblewrap HOT 13 CLOSED

If this is actually a kernel option, then bubblewrap may need to take a --with-clone-backwards=X or so.

from bubblewrap.

glibc doesn't seem to make any attempt to handle non-default argument order, at least on ARM: http://sources.debian.net/src/glibc/2.23-1/sysdeps/unix/sysv/linux/arm/clone.S/#L19. I suspect that the "option" is just to unify architectures that happen to do it the same way, rather than being something usefully user-settable.

from bubblewrap.

config CLONE_BACKWARDS
        bool
        help
          Architecture has tls passed as the 4th argument of clone(2),
          not the 5th one.

config CLONE_BACKWARDS2
        bool
        help
          Architecture has the first two arguments of clone(2) swapped.

config CLONE_BACKWARDS3
        bool
        help
          Architecture has tls passed as the 3rd argument of clone(2),
          not the 5th one.

I don't see how BACKWARDS or BACKWARDS3 would affect bubblewrap, which only passes the first two arguments anyway?

from bubblewrap.

Can't we do a runtimes check?

from bubblewrap.

Can't we do a runtimes check?

How? /boot/config-* isn't guaranteed to either exist or correspond to the running kernel.

from bubblewrap.

For instance, call clone() with a flags that guarantees EINVAL (say NEWUSER|THREAD), but a valid flag as stack pointer (NULL maybe?). Then you'll see if the call worked, if not reverse the args.

from bubblewrap.

From a quick trawl through codesearch.debian.net, none of the packages in Debian that call the raw clone syscall seem to have anything more complex than an #ifdef. Many of them explicitly pass the 3rd, 4th and 5th arguments (as NULL) - I wonder whether we should be doing that, to guarantee that the struct pt_regs * is NULL?

Swapping the flags and child stack is BACKWARDS2, which isn't what's in @hadess's kernel configuration, so I think he might actually be passing flags = 0 and a weird pointer for the stack?

from bubblewrap.

None of the architectures I looked at in glibc make any effort to handle non-default argument orders, either: they all assume that the argument order is ABI.

from bubblewrap.

I think this is some other reason for EINVAL (I hate kernel-style error-reporting). My Raspberry Pi 2 with a patched Debian-based kernel has the same clone() backwardsness as @hadess' CHIP, and seems to be fine for basic use of bwrap:

smcv@rpi2:~$ uname -a
Linux rpi2 4.2.0-1-rpi2 #1 SMP PREEMPT Debian 4.2.5-1+rpi+1 (2015-10-31) armv7l GNU/Linux
smcv@rpi2:~$ grep CLONE /boot/config-4.2.0-1-rpi2 
CONFIG_CLONE_BACKWARDS=y
smcv@rpi2:~$ bwrap --ro-bind / / /bin/true; echo $?
0

from bubblewrap.

Working kernel configuration (at least for basic uses), if you want to compare: https://www.pseudorandom.co.uk/~smcv/20160706rpicfg/config-4.2.0-1-rpi2

from bubblewrap.

You don't have to do runtime checks, the "option" is just a compile-time flag. I think all but one weird architecture use a hard-coded "configuration". It's not user-settable, that wouldn't even make sense.

from bubblewrap.

@hadess: do really basic uses of bwrap, like the ones in https://anonscm.debian.org/cgit/collab-maint/bubblewrap.git/tree/debian/tests, work on your CHIP? I wonder whether this might be a problem with a specific command-line option, maybe --unshare-something.

If you use something like strace -f -ewrite,execve -s10000 flatpak ... you should see a very long write() to a fd, with \0-separated command-line options for bwrap, followed by a bwrap call with --args (some fd).

Using a much simpler flatpak app, like the one for xvt described in http://smcv.pseudorandom.co.uk/2016/xdg-app/, might get you a little closer to having a minimal reproducer by not doing as much?

from bubblewrap.

After rebuilding a 4.4 kernel for that machine with the patches at:
https://github.com/NextThingCo/CHIP-linux/pull/38

The bubblewrap Debian test suite passes.

The bug for documenting the necessary kernel configuration is:
#87

The original issue is fixed, and there should be no need to switch parameter order in this code beyond what is already done.

from bubblewrap.