test-82ba4ba1: Add support for a new behavior of chroot(1) + fix a typo.

    chroot with an argument of "/" no longer implicitly changes the
    current directory to "/", allowing changing only user credentials
    for a command.

    -- Coreutils-8.23 Changelog

Note that only the behavior of the tool has changed, not the behavior
of the syscall.

Reported-by: Rémi Duraffort <remi.duraffort@st.com>
care: Escape all ' (single quote) characters from env. variable values.
Allow dynamically linked versions of CARE.

The new "raw" format was introduced, it is the default when CARE is
not built as a portable binary to force users to use `care -x` to
extract files.  Also, proot is not copied into the archive if CARE was
not built as a portable binary, instead the re-execute.sh script tries
to retrieve proot from $PATH or $PROOT.
Make obj-ification in the build-system works whatever $LANG is.

A regular expression is used to know the format and architecture used
by the toolchain, this information is required to link random stuff
(manual, licenses) with the final binary (care or proot).  This
regular expression matches only the text if "LANG=C".

Reported-by: Rémi Duraffort <remi.duraffort@st.com>
Reproduced-with: CARE http://reproducible.io

Yes, CARE is used to reproduce bugs in CARE's build-system :)
care: Emulate syscalls only if it is really needed.

Some syscalls are not fully emulated by the "kompat" extension, so in
doubt don't emulate syscalls that are supported by the running kernel.
kompat: Check that the replacing syscall exists on the current architecture.

They are a lot of syscalls that do not exist on Aarch64.  For
instance, the glibc wrapper for open(2) uses openat(2).

Reported-by: Rémi Duraffort <remi.duraffort@st.com>
Make -0 and -S options (ie. fake_id0 extension) fake success of mknodat(2).

This issue was exposed by test d1be631a on AArch64.

Reported-by: Rémi Duraffort <remi.duraffort@st.com>
Don't emulate suspicious call to brk(2), they might be legit after all.

PRoot might believe that a tracee is calling brk(2) for the first time
with a specific address (this is not supposed to happen the first
time).  It is likely because such tracee is the very first child of
PRoot but the first execve(2) didn't happen yet (so this is not its
first call to brk(2)).  For instance, the installation of seccomp
filters is made after this very first process is traced, and might
call malloc(3) before the first execve(2).

This issue was exposed on a minimal Debian Sid x86_64:

    root@kvm03:~/PRoot# ./src/care -o test.cpio cat
    [...]
    care warning: process 13255 is doing suspicious brk()
    care info: pid 13255: terminated with signal 11
    [...]

Reported-by: Rémi Duraffort <remi.duraffort@st.com>
Disable heap emulation everywhere when a suspicious call to brk(2) is legit.

This commit completes the previous one.
Fix "warning: ‘return’ with a value, in function returning void".
Prepare release of PRoot v4.0.3 and CARE v2.2.
Prepare release of PRoot v4.0.3 and CARE v2.2 (2/2).
Add a missing header for CARE.

This issue was exposed on Slackware-14.0.
Extract all load information from the executed binary.

The aim of this branch is to get a new "execve" module in PRoot that
will contain the so much awaited loader :)
Split new execve module in 2 (sysenter & sysexit) + align load addresses.

Before:

    $ ./src/proot grep . /proc/self/maps
    0000000000400000-000000000045227c r-xp 0000000000000000 00:00 0 /bin/grep
    0000000000652280-0000000000654860 rw-p 0000000000052280 00:00 0 /bin/grep
    0000000000000000-0000000000022cd8 r-xp 0000000000000000 00:00 0 /lib64/ld-2.17.so
    0000000000223be8-0000000000225268 rw-p 0000000000023be8 00:00 0 /lib64/ld-2.17.so

    00400000-00453000 r-xp 00000000 fd:01 1180089                            /bin/grep
    00652000-00654000 rw-p 00052000 fd:01 1180089                            /bin/grep
    [...]
    7fcd81a60000-7fcd81a83000 r-xp 00000000 fd:01 274754                     /lib64/ld-2.17.so
    7fcd81c83000-7fcd81c84000 r--p 00023000 fd:01 274754                     /lib64/ld-2.17.so
    7fcd81c84000-7fcd81c86000 rw-p 00024000 fd:01 274754                     /lib64/ld-2.17.so

Now:

    $ ./src/proot grep . /proc/self/maps
    0000000000400000-0000000000453000 r-xp 0000000000000000 00:00 0 /bin/grep
    0000000000652000-0000000000654000 rw-p 0000000000052000 00:00 0 /bin/grep
    0000000000654000-0000000000655000 rw-p 00000000 00:00 0
    0000000000000000-0000000000023000 r-xp 0000000000000000 00:00 0 /lib64/ld-2.17.so
    0000000000223000-0000000000226000 rw-p 0000000000023000 00:00 0 /lib64/ld-2.17.so

    00400000-00453000 r-xp 00000000 fd:01 1180089                            /bin/grep
    00652000-00654000 rw-p 00052000 fd:01 1180089                            /bin/grep
    00654000-00655000 rw-p 00000000 00:00 0
    [...]
    7f2e8c4a4000-7f2e8c4c7000 r-xp 00000000 fd:01 274754                     /lib64/ld-2.17.so
    7f2e8c6c7000-7f2e8c6c8000 r--p 00023000 fd:01 274754                     /lib64/ld-2.17.so
    7f2e8c6c8000-7f2e8c6ca000 rw-p 00024000 fd:01 274754                     /lib64/ld-2.17.so
Implement a trivial loader generator (it produces C code).

To use this loader (for ex.):

    $ ./src/proot grep . /proc/self/maps 2>loader.c
    $ gcc -fpie -pie loader.c
    $ strace ./a.out
    [...]
    open("/bin/grep", O_RDONLY)             = 3
    mmap(0x400000, 339968, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400000
    mmap(0x652000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0x52000) = 0x652000
    mmap(0x654000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x654000
    close(3)                                = 0
    open("/lib64/ld-2.17.so", O_RDONLY)     = 3
    mmap(NULL, 143360, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fb1c3bc3000
    mmap(0x7fb1c3de6000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0x23000) = 0x7fb1c3de6000
    close(3)                                = 0
Initial import of the remote loader (a.k.a new execve module).

To enable the remote loader:

    env CPPFLAGS=-DEXECVE2 make -C src/

To test the remote loader:

    $ ./src/proot -v 5 /lib64/ld-linux-x86-64.so.2
    [...]
    ptrace acceleration (seccomp mode 2) enabled
    pid 123: sysenter start: execve(0x259ebf0, 0x259c7a0, 0x7fff694ea190, 0x7fff694e9df0, 0xe8150c73, 0x7f4cf85287d8) = 0xffffffffffffffda [0x7fff694e9f98, 0]
    pid 123: translate("/" + "/lib64/ld-linux-x86-64.so.2")
    pid 123:          -> "/lib64/ld-2.17.so"
    pid 123: sysenter end: execve(0x7fff694e9ee5, 0x259c7a0, 0x7fff694ea190, 0x7fff694e9df0, 0xe8150c73, 0x7f4cf85287d8) = 0xffffffffffffffda [0x7fff694e9ee5, 0]
    pid 123: sysexit start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x0 [0x7fff962945d0, 0]
    pid 123: sysexit end: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3b [0x7fff962945d0, 0]
    pid 123: sysenter start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945d0, 0]
    pid 123: sysenter end: open(0x7fff962945be, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysexit start: open(0x7fff962945be, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3 [0x7fff962945be, 0]
    pid 123: sysexit end: open(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3b [0x7fff962945be, 0]
    pid 123: sysenter start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysenter end: mmap(0x0, 0x23000, 0x5, 0x2, 0x3, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysexit start: mmap(0x0, 0x23000, 0x5, 0x2, 0x3, 0x0) = 0x7f5fd856a000 [0x7fff962945be, 0]
    pid 123: sysexit end: mmap(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3b [0x7fff962945be, 0]
    pid 123: sysenter start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysenter end: mmap(0x7f5fd878d000, 0x2000, 0x3, 0x2, 0x3, 0x23000) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysexit start: mmap(0x7f5fd878d000, 0x2000, 0x3, 0x2, 0x3, 0x23000) = 0x7f5fd878d000 [0x7fff962945be, 0]
    pid 123: sysexit end: mmap(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3b [0x7fff962945be, 0]
    pid 123: sysenter start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysenter end: mmap(0x7f5fd8790000, 0x1000, 0x3, 0x22, 0xffffffffffffffff, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysexit start: mmap(0x7f5fd8790000, 0x1000, 0x3, 0x22, 0xffffffffffffffff, 0x0) = 0x7f5fd8790000 [0x7fff962945be, 0]
    pid 123: sysexit end: mmap(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x3b [0x7fff962945be, 0]
    pid 123: sysenter start: execve(0x0, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysenter end: close(0x3, 0x0, 0x0, 0x0, 0x0, 0x0) = 0xffffffffffffffda [0x7fff962945be, 0]
    pid 123: sysexit start: close(0x3, 0x0, 0x0, 0x0, 0x0, 0x0) = 0x0 [0x7fff962945be, 0]
    pid 123: sysexit end: execve(0x259ebf0, 0x259c7a0, 0x7fff694ea190, 0x7fff694e9df0, 0xe8150c73, 0x7f4cf85287d8) = 0x0 [0x7fff694e9f98, 0]
    pid 123: translate("/" + "/lib64/ld-linux-x86-64.so.2")
    pid 123:          -> "/lib64/ld-linux-x86-64.so.2"
    pid 123: terminated with signal 11

It is expected to fail since the loader doesn't set the instruction
pointer correctly yet (nor the ELF auxiliary vectors).
Compute mapping lengths correctly + set the instr. pointer to the entry point.

Mapping lengths must be computed once the start and end addresses are
paged-align.

So far, it is possible to execute this command:

    $ setarch x86_64 -R ./src/proot /lib64/ld-linux-x86-64.so.2
    Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
    You have invoked `ld.so', the helper program for shared library executables.
    This program usually lives in the file `/lib/ld.so', and special directives
    [...]
Set AT_PH* auxiliary vectors + "load map" -> "load info".

It is now possible to execute static executable:

    $ ./src/proot ./tests/rootfs/bin/echo OK

Current limitations:

- AT_PHDR value is hardcoded

- path to the stub is hardcoded

- the stub base address must not conflict with the program base
  address

- dynamic executable not supported yet
Rename module "tracee/array" into "execve/aoxp" and improve its semantic.

The terms "array" and "item" were too much misleading.  Instead, these
terms are now used:

- xpointer: pointer to a object into tracee's memory space that can be
  cached into tracer's memory space.

- array of xpointers: high level structure used to handle pointer
  tables.