mirror of
https://github.com/libguestfs/libguestfs.git
synced 2026-03-21 22:53:37 +00:00
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.
REAMDE for the Erlang bindings to libguestfs ---------------------------------------------------------------------- To get started, take a look at the man page guestfs-erlang(3) and the example programs. Note that to run the examples, the "erl-guestfs" binary must be on the path. To run the examples without installing, do: cd erlang PATH=.:$PATH ../run ./examples/create_disk.erl PATH=.:$PATH ../run ./examples/inspect_vm.erl /path/to/vm_disk.img To simplify the implementation we currently don't support events or user cancellation. However it would be pretty simple to add both of these. Patches welcome! Implementation notes ---------------------------------------------------------------------- These bindings are done using a port that launches an external program, following this example: http://www.erlang.org/doc/tutorial/erl_interface.html The reason for this is that the libguestfs API is synchronous and calls may take a long time. If we used a linked-in driver then that would require us to start a POSIX thread in the Erlang interpreter and manage concurrency issues. Using an external process per handle simplifies the implementation and makes it much less likely to break the Erlang interpreter. The external C program is called "erl-guestfs". It is normally installed in $(bindir), eg. /usr/bin/erl-guestfs. You need to make sure that the Erlang code and erl-guestfs are the same version. The protocol used between the Erlang code (guestfs.erl) and erl-guestfs might change in future versions. There is not really any type checking done in the erl-guestfs binary, which means you can get undefined behaviour if you send incorrect argument types. Patches welcome to improve this situation. Licensing ---------------------------------------------------------------------- Because the C program runs in a separate process, it is licensed as GPLv2+. The Erlang part which "links" into the Erlang interpreter is licensed as LGPLv2+. We believe this means there is no impediment to using libguestfs from closed source Erlang programs. The example programs are under a separate, very permissive license, which basically allows you to do what you want with them. See erlang/examples/LICENSE.