I couldn't get GCC 10.1 to ignore this warning any longer, possibly
because I am using LTO. In any case dereferencing a pointer is
undefined behaviour, so let's use GCC's __builtin_trap() function
instead (also supported by clang).
debug.c: In function 'debug_segv':
debug.c:1002:8: error: null pointer dereference [-Werror=null-dereference]
1002 | *ptr = 1;
| ^
GUESTFSD_EXT_CMD was used by OpenSUSE to track which external commands
are run by the daemon and package those commands into the appliance.
It is no longer used by recent SUSE builds, so remove it.
Thanks: Pino Toscano, Olaf Hering.
After the previous refactoring, we are able to link the daemon to
common/utils, and also remove some of the "duplicate" functions that
the daemon carried ("duplicate" in quotes because they were often not
exact duplicates).
Also this removes the duplicate reimplementation of (most) cleanup
functions in the daemon, since those are provided by libutils now.
It also allows us in future (but not in this commit) to move utility
functions from the daemon into libutils.
GCC 7.0.1 can determine if there is likely to be sufficient space in
the output buffer when using sprintf/snprintf, based on the format
string.
The errors were all either of this form:
bindtests.c:717:29: error: '%zu' directive output may be truncated writing between 1 and 19 bytes into a region of size 16 [-Werror=format-truncation=]
snprintf (strs[i], 16, "%zu", i);
^~~
bindtests.c:717:28: note: directive argument in the range [0, 2305843009213693951]
snprintf (strs[i], 16, "%zu", i);
^~~~~
or this form:
sync.c: In function 'fsync_devices':
sync.c:108:50: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 251 [-Werror=format-truncation=]
snprintf (dev_path, sizeof dev_path, "/dev/%s", d->d_name);
^~
Fixed by converting these into dynamic allocation, or making the
output buffer larger, whichever was easier.
There is a gnulib macro we can use to make this simpler for integers.
It requires a new gnulib module (intprops), but it turns out that we
were already pulling that in through dependencies, so the change to
bootstrap is a no-op. (thanks: Dan Berrange)
Run the following command over the source:
perl -pi.bak -e 's/(20[01][0-9])-2016/$1-2017/g' `git ls-files`
(Thanks Rich for the perl snippet, as used in past years.)
-Wnull-dereference and -Wshift-overflow are new warnings in GCC 6, so do
not try to disable them with pragmas on older GCC versions.
Fixes commit a8e15ea924.
One -Wnull-dereference warning is real: we deliberately cause a
segfault in one of the tests.
There is a -Wshift-overflow bug in a Gtk 2 header.
The others are the result of shortcomings in GCC.
In all cases we have to add GCC diagnostic overrides to ignore
the warnings when compiling with ./configure --enable-werror.
GCC has two warnings related to large stack frames. We were already
using the -Wframe-larger-than warning, but this reduces the threshold
from 10000 to 5000 bytes.
However that warning only covers the static part of frames (not
alloca). So this change also enables -Wstack-usage=10000 which covers
both the static and dynamic usage (alloca and variable length arrays).
Multiple changes are made throughout the code to reduce frames to fit
within these new limits.
Note that stack allocation of large strings can be a security issue.
For example, we had code like:
size_t len = strlen (fs->windows_systemroot) + 64;
char software[len];
snprintf (software, len, "%s/system32/config/software",
fs->windows_systemroot);
where fs->windows_systemroot is guest controlled. It's not clear what
the effects might be of allowing the guest to allocate potentially
very large stack frames, but at best it allows the guest to cause
libguestfs to segfault. It turns out we are very lucky that
fs->windows_systemroot cannot be set arbitrarily large (see checks in
is_systemroot).
This commit changes those to large heap allocations instead.
This seemingly redundant change avoids a gcc warning/error:
error: cannot optimize possibly infinite loops
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114#c3 and
following for an explanation.
Of course gcc is completely wrong and stupid here, because there's no
possibility on current or future hardware that an array of size
SSIZE_MAX could be allocated since it would by definition occupy at
least all addressible memory (if it was an array of bytes, which this
isn't), leaving no room for the code that is being compiled.
When the user has enabled the network (not the default) we upload
/etc/resolv.conf from the host to the appliance /etc/resolv.conf
so that programs in the appliance can contact nameservers.
Commit 9521422ce6 previously changed the
behaviour to copy /etc/resolv.conf into the sysroot when running
commands.
Code like:
CLEANUP_FREE char *buf;
/* some code which might return early */
buf = malloc (10);
is a potential bug because the free (*buf) might be called when buf is
an uninitialized pointer. Initialize buf = NULL to avoid this.
Several of these are bugs, most are not bugs (because there is no
early return statement before the variable gets initialized).
However the compiler can elide the initialization, and even if it does
not the performance "penalty" is miniscule, and correctness is better.
This involves adding a new test API which crashes the appliance in the
middle of a simulated upload, then a test which uses that API to test
for the libguestfs (library-side) crash.
There are now two forms of the 'debug progress' command:
(1) debug progress <n> (the original form) generates ordinary
rate-limited progress messages for <n> seconds.
(2) debug progress <n> <rate> generates progress messages every <rate>
microseconds for <n> seconds.
The second form omit the usual rate-limiting, and so wouldn't
be generated like this from an ordinary API call. However this
is useful for testing events (see RHBZ#909624).
Using // coverity[...] or /* coverity[...] */ comments in the source
it is possible to suppress specific Coverity errors. The suppressed
error should occur in the line following the comment.
In this case I have suppressed two false positives from Coverity:
(a) We deliberately assign to a NULL pointer in order to cause a
segfault, for testing how the library reacts when this happens.
Coverity flags this, but it is not an error in this case.
(b) Coverity does not model global variables (a known shortcoming).
Therefore the code 'errno = posix_memalign (...)' cannot be modelled
by Coverity, even though the code is correct. Coverity raises a false
positive about this.
(Thanks Kamil Dudka, Coverity)
guestfsd calls many different tools. Keeping track of all of them is
error prone. This patch introduces a new helper macro to put the command
string into its own ELF section:
GUESTFSD_EXT_CMD(C_variable, command_name);
This syntax makes it still possible to grep for used command names.
The actual usage of the collected list could be like this:
objcopy -j .guestfsd_ext_cmds -O binary daemon/guestfsd /dev/stdout |
tr '\0' '\n' | sort -u
The resulting output will be used to tell mkinitrd which programs to
copy into the initrd.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
RWMJ:
- Move str_vgchange at request of author.
- Fix snprintf call in daemon/debug.c
The presumption is that all file descriptors should be created with
the close-on-exec flag set. The only exception are file descriptors
that we want passed through to exec'd subprocesses (mainly pipes and
stdin/stdout/stderr).
For open calls, we pass O_CLOEXEC as an extra flag, eg:
fd = open ("foo", O_RDONLY|O_CLOEXEC);
This is a Linux-ism, but using a macro we can easily make it portable.
For sockets, similarly:
sock = socket (..., SOCK_STREAM|SOCK_CLOEXEC, ...);
For accepted sockets, we use the Linux accept4 system call which
allows flags to be supplied, but we use the Gnulib 'accept4' module to
make this portable.
For dup, dup2, we use the Linux dup3 system call, and the Gnulib
modules 'dup3' and 'cloexec'.
Error: RESOURCE_LEAK:
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:469: open_fn: Calling opening function "open".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:469: var_assign: Assigning: "fd" = handle returned from "open("/proc/sys/kernel/core_pattern", 1)".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:474: noescape: Variable "fd" is not closed or saved in function "write".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:476: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
When given an invalid debug command, libguestfs responds with the
error message:
libguestfs: error: debug: use 'debug help' to list the supported commands
However this command does not work, as debug requires two
arguments. This change updates the message to prompt the user to use
'debug help 0'.
In the case where both ends cancel at the same time (eg. both ends
realize there are errors before or during the transfer), previously we
skipped sending back an error from the daemon, on the spurious basis
that the library would not need it (the library is cancelling because
of its own error).
However this is wrong: we should always send back an error message
from the daemon in order to preserve synchronization of the protocol.
A simple test case is:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
libguestfs: error: unexpected procedure number (66/282)
(Notice two things: there are errors at both ends, and the
loss of synchronization).
After applying this commit, the loss of synchronization does not occur
and we just see the library error:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
The choice of displaying the library or the daemon error is fairly
arbitrary in this case -- it would be valid to display either or even
to combine them into one error. Displaying the library error only
makes the code considerably simpler.
This commit also (re-)enables a test for this case.
The debug command is useful for internal testing, and so should
be enabled by default in all builds.
Note that it is still *not* part of the stable ABI.
This adds a new debug command, core_pattern, which writes a new pattern for
coredump files to the appliance kernel, and sets the daemon's hard and soft core
limits to infinity.
Allow arbitrary files to be uploaded into the appliance, but
only when --enable-debug-command is enabled. This lets you
run shell scripts, like this:
><fs> debug-upload -<<EOF /tmp/script.sh 0700
#!/bin/sh -
# ...
EOF
><fs> debug sh "/tmp/script.sh"
