The semantics of --host-lo-to-ns-lo as described in the man page don't
quite make sense: It says without the option forwarded packets will appear
to come _from_ the guest's public address, which is not usually true.
Instead the packets will arrive *to* the guest's public address.  The exact
semantics are also a bit confusing in general.

Rewrite both the man page and code to clarify this.  The new rule is that
it redirects connections addressed to a host loopback address to the same
loopback address in the guest.  This is notionally different from what we
had in two ways:
  * We can now deliver to nonstandard loopback addresses within the guest,
    not just the default one.  This is technically a behavioural change,
    but I think will be less surprising behaviour.
  * The decision is now made on the original _destination_ address, rather
    than source address.  That's different theoreically, but not in
    practice, since loopback packets must have loopback addresses for both
    source and destination.

We make it explicitly incompatible with --no-splice - previously it
was allowed, but would have no effect in that case.

As well as being more precise right now, these semantics will intersect
better with upcoming remapping of target address by forwarding rules.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

For integrations, which use rootfs on tmpfs or initramfs, it is not
allowed to use pivot_root(). It results with invalid argument (EINVAL)
error. Introduce --chroot-fallback option as a workaround with
MS_MOVE + chroot().

Due to weaker isolation of chroot() method (we don't unmount old root),
user has tu explicitly enable fallback with the new option. First,
always try to sandbox with pivot_root(). In both cases the new root is
placed into an empty tmpfs.

For the solution to work we keep CAP_SYS_CHROOT capability, which is
dropped at the end of the isolate_prefork() function.

Link: https://bugs.passt.top/show_bug.cgi?id=104
Signed-off-by: Mateusz Andrzejewski <mateusz.andrzejewski@mikronika.com.pl>
[sbrivio: Minor tweaks to comments, usage, man page]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Extend the parsing of forwarding rules (-[tu]) to allow the destination
address on the target side to be specified.  For now just parse them, and
give an error if we try to create rules with a specified target address.
We'll implement the actual forwarding logic in another patch.

Format (for either command line or pesto):
      -t 2222:192.0.2.1/2222

This should work along with all the other bits, that is, say:
      -t 192.0.2.1%eth0/2222-2225:192.0.2.2/22-25

FIXME: Ban for -[TU] for now
FIXME: Check interaction with splice handling

[dwg: Syntax from Stefano's earlier draft, largely rewritten on top of new
 parsing helpers]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Currently we handle -t all and the like as a special case, it can't be
combined with other port specifier options.  Remove that restriction,
allowing combined options like:
     -t all,~9999          # Forward everything non-ephemeral except 9999
     -t all,auto           # Equivalent to -t auto
     -t all,33000          # Forward non-ephemeral plus port 33,000

This isn't particularly useful immediately, but will become important for
destination address specification - it provides a place to attach the
target address for "all" or exclude only mappings.  It will also work
better with some parsing reworks we want to make.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Start implementing pesto in earnest.  Create a control/configuration
socket in passt.  Have pesto connect to it and retrieve a server greeting
Perform some basic version checking.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Avoid potential recursive calling between conf_accept() and
 conf_close(), reported by clang-tidy]
[sbrivio: In conf(), check we're not exceeding sizeof(c->control_path)
 instead of sizeof(c->socket_path), and, in pesto's main(), print
 argv[optind] instead of argv[1] to indicate an invalid socket path,
 both reported by Jon Maloy]
[sbrivio: In pesto's main(), drop unnecessary newline from error
 message, reported by Laurent]
[sbrivio: Don't use SOCK_NONBLOCK on accept4(), as that only applies
 to the *new* file descriptor, which we don't want -- set O_NONBLOCK
 on the listening file descriptor using fcntl()]
[sbrivio: Switch to protocol version 1, and reflect the true magic
 behind pesto, i.e. basil, into the magic string]
[sbrivio: Fix conflicts in the Makefile caused by the fact that I'm
 not merging a previous series reworking it]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>

The forwarding table now allows for arbitrary port ranges to be marked as
FWD_SCAN, meaning we don't open sockets for every port, but only those we
scan as listening on the target side.  However, there's currently no way
to create such rules, except -[tTuU] auto which always scans every port
with an unspecified listening address and interface.

Allow user-specified "auto" ranges by moving the parsing of the "auto"
keyword from conf_ports(), to conf_ports_spec() as part of the port
specified.  "auto" can be combined freely with other port ranges, e.g.
    -t 127.0.0.1/auto
    -u %lo/5000-7000,auto
    -T auto,12345
    -U auto,~1-9000

Note that any address and interface given only affects where the automatic
forwards listen, not what addresses we consider when scanning.  That is,
if the target side is listening on *any* address, we will create a forward
on the specified address.

Link: https://bugs.passt.top/show_bug.cgi?id=180
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
[sbrivio: Fix extra space after if (isdigit(*p)) reported by Laurent]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Currently -[tTuU] all is handled separately in conf_ports() before calling
conf_ports_spec().  Earlier changes mean we can now move this handling to
conf_ports_spec().  This makes the code slightly simpler, but more
importantly it allows some useful combinations we couldn't previously do,
such as
	-t 127.0.0.1/all
or
	-u %eth2/all

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Currently the man page describes the internal syntax of port specifiers
in prose, which isn't particularly easy to follow.  Rework it to use
more syntax "diagrams" to show how it works.  This will also allow us to
more easily update the manual page for some coming changes in syntax.

usage() output is updated similarly, though more briefly.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Currently we explicitly forbid -[tTuU] all in pasta mode.  While these are
primarily useful for passt, there's no particular reason they can't be
used in pasta mode as well.  Indeed you can do the same thing in pasta
by using "-t ~32768-60999" (assuming default Linux configuration of
ephemeral ports).  For consistency, permit "all" for pasta as well.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

The man page currently has two fairly large, near-identical sections
separately describing the -t and -u options for passt and pasta.  This is
bulky and potentially confusing.  It will make this information more
tedious to update as we alter what's possible here with the forwarding
table.  Consolidate both descriptions to a single one in the common
options, noting the few passt/pasta difference inline.

There's similar duplication usage(), consolidate that as well.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>