The situation is improved now that we're running in a sandbox, but there
is still some host machine access that could be concerning depending on
the context. These concerns may be somewhat mitigated by the fact that
the host machine usually provides the loader binary, even when the guest
image is providing the loader scripts -- they only bring the lua
scripts, and they have to be able to execute arbitrary syscalls rather
than the interfaces provided by libsa(3).
Reviewed by: jhb, markj
Differential Revision: https://reviews.freebsd.org/D43299
In the case of hostbase_fd, this is infact a bug fix; we have a seek
callback that the host: filesystem may use in loader, and we really
don't have a good excuse to break it.
bootfd-derived fds will only be used with fdlopen(3) and rtld doesn't
seem to need pread / lseek at all for it today, but there's no reason to
break if it finds a good reason to later.
Suggested by: markj
Previously we used a mix of perror(3) + exit(3) and err(3); standardize
on the latter instead. This does remove one free() in an error path,
because we're decidedly leaking a lot more than just the loader name
there (loader handle, vcpu, vmctx...) anyways.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43331
userboot has a EXIT_REBOOT code that it uses when the 'reboot' loader
command is executed. Use that and longjmp back to reinit the VM
entirely with a reboot request. This fixes the 'reboot' option in the
loader menu to actually reboot rather than shutdown the VM.
The JMP_* constants are introduced to keep track of why we're doing a
longjmp, though they aren't currently used. We'll notably still do a
complete reload of the interpreter to give the rebooted VM that new
loader smell. It just seemed forward thinking to just keep track of the
different setjmp points.
While we're here, we don't actually need to keep the fd we passed to
fdlopen(3), so let's avoid leaking it.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43300
In neither case do we need write access to the directories we're working
with; userboot doesn't support fo_write on the host device, and the
bootfd is only ever needed for loader loading.
This improves on 8bf0882e18 ("bhyveload: enter capability mode [...]")
so that arbitrary code in the loader can't open writable fds to either
of the directories we need to maintain access to.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43315
explicit_loader_fd should have been initialized to -1, not 0, but my
last round of testing was only with -l...
Fixes: bf7c4fcbbb ("bhyveload: hold /boot and do relative [...]")
Pointy hat: kevans
The next change will push bhyveload into capability mode right after we
allocate vcpu state, before we've setup or entered the loader, to limit
the surface area that a rogue loader script can touch.
With an explicit -l loader, we don't need to preopen /boot because
changing interpreters isn't allowed. We'll just dlopen() entirely in
advance in that case to eliminate some complexity.
Reviewed by: allanjude (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D43285
Don't allow lookups from the loader scripts, which in rare cases may be
in guest control depending on the setup, to leave the specified host
root. Open the root dir and strictly do RESOLVE_BENEATH lookups from
there.
cb_open() has been restructured a bit to work nicely with this, using
fdopendir() in the directory case and just using the fd we already
opened in the regular file case.
hostbase_open() was split out to provide an obvious place to apply
rights(4) if that's something we care to do.
Reviewed by: allanjude (earlier version), markj
Differential Revision: https://reviews.freebsd.org/D43284
After removing the -FreeBSD and -NetBSD, we're left with a nuber of
BSD-2-Clause AND BSD-2-Clause, so tidy that up.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This replaces the 'struct vm, int vcpuid' tuple passed to most API
calls and is similar to the changes recently made in vmm(4) in the
kernel.
struct vcpu is an opaque type managed by libvmmapi. For now it stores
a pointer to the VM context and an integer id.
As an immediate effect this removes the divergence between the kernel
and userland for the instruction emulation code introduced by the
recent vmm(4) changes.
Since this is a major change to the vmmapi API, bump VMMAPI_VERSION to
0x200 (2.0) and the shared library major version.
While here (and since the major version is bumped), remove unused
vcpu argument from vm_setup_pptdev_msi*().
Add new functions vm_suspend_all_cpus() and vm_resume_all_cpus() for
use by the debug server. The underyling ioctl (which uses a vcpuid of
-1) remains unchanged, but the userlevel API now uses separate
functions for global CPU suspend/resume.
Reviewed by: corvink, markj
Differential Revision: https://reviews.freebsd.org/D38124
Mostly sprinkle __unused. Also duplicate strings passed to addenv() so
that constant string literals can be passed. No functional change
intended.
Reviewed by: corvink, rew, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38840
When a boot environment has been booted via the bootonce feature,
userboot clears the bootonce value from an nvlist but fails to write the
updated nvlist back to disk.
The failure occurs because bhyveload opens the guest boot disk image
O_RDONLY, fix this by opening it O_RDWR.
Reviewed by: imp, markj, jhb
Differential Revision: https://reviews.freebsd.org/D37274
The method was optional prior to r365938, which made it mandatory but did add
any test that an implementation provides the method nor implement it for
bhyveload. The code path might not be hit unless the user's loader was
configured to write to a file on disk, such as with nextboot(8).
Reviewed by: grehan, tsoome
Approved by: bhyve
X-MFC-With: r365938
Differential Revision: https://reviews.freebsd.org/D26710
We need a valid st_dev, st_ino and st_mtime
to correctly track which files have been verified
and to update our notion of time.
ve_utc_set(): ignore utc if it would jump our current time
by more than VE_UTC_MAX_JUMP (20 years).
Allow testing of install command via userboot.
Need to fix its stat implementation too.
bhyveload also needs stat fixed - due to change to userboot.h
Call ve_error_get() from vectx_close() when hash is wrong.
Track the names of files we have hashed into pcr
For the purposes of measured boot, it is important
to be able to reproduce the hash reflected in
loader.ve.pcr
so loader.ve.hashed provides a list of names in the order they
were added.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D24027
The switch to lualoader creates a problem with userboot: the host is
inclined to build userboot with Lua, but the host userboot's interpreter
must match what's available on the guest. For almost all FreeBSD guests in
the wild, Lua is not yet available and a Lua-based userboot will fail.
This revision updates userboot protocol to version 5, which adds a
swap_interpreter callback to request a different interpreter, and tries to
determine the proper interpreter to be used based on how the guest
/boot/loader is compiled. This is still a bit of a guess, but it's likely
the best possible guess we can make in order to get it right. The
interpreter is now embedded in the resulting executable, so we can open
/boot/loader on the guest and hunt that down to derive the interpreter it
was built with.
Using -l with bhyveload will not allow an intepreter swap, even if the
loader specified happens to be a userboot with the wrong interpreter. We'll
simply complain about the mismatch and bail out.
For legacy guests without the interpreter marker, we assume they're 4th.
For new guests with the interpreter marker, we'll read it and swap over
to the proper interpreter if it doesn't match what the userboot we're using
was compiled with.
Both flavors of userboot are installed by default, userboot_4th.so and
userboot_lua.so. This fixes the build WITHOUT_FORTH as a coincidence, which
was broken by userboot being forced to 4th.
Reviewed by: imp, jhb, araujo (earlier version)
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D16945
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
On FreeBSD fstat(2) works fine for querying sizes of plain files,
but not so much for character devices.
So, use DIOCGMEDIASIZE to try to get the correct size for disks
and disk-like devices (e.g. zvols).
PR: 220186
Reviewed by: tsoome, grehan
MFC after: 1 week
A couple of minor memory size option related nits:
- use common name 'memsize' (instead of 'max-size' or just 'size')
- bhyve: update usage with memsize unit suffix, drop legacy "MB"
unit
- bhyveload: update usage with memsize unit suffix
- bhyve(8): document default size
- bhyveload(8): use memsize formatting like it's done
in bhyve(8)
Reviewed by: wblock, grehan
Approved by: re (kib), wblock, grehan
Differential Revision: https://reviews.freebsd.org/D6952
We were setting an incorrect/undefined size and as it came out the st
struct was not really being used at all. This was actually a bug but
by sheer luck it had no visual effect.
CID: 1194320
Reviewed by: grehan
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
devmem is used to represent MMIO devices like the boot ROM or a VESA framebuffer
where doing a trap-and-emulate for every access is impractical. devmem is a
hybrid of system memory (sysmem) and emulated device models.
devmem is mapped in the guest address space via nested page tables similar
to sysmem. However the address range where devmem is mapped may be changed
by the guest at runtime (e.g. by reprogramming a PCI BAR). Also devmem is
usually mapped RO or RW as compared to RWX mappings for sysmem.
Each devmem segment is named (e.g. "bootrom") and this name is used to
create a device node for the devmem segment (e.g. /dev/vmm/testvm.bootrom).
The device node supports mmap(2) and this decouples the host mapping of
devmem from its mapping in the guest address space (which can change).
Reviewed by: tychon
Discussed with: grehan
Differential Revision: https://reviews.freebsd.org/D2762
MFC after: 4 weeks
bhyveload would allow you to create 33 entries on an array that only has 32 slots
Differential Revision: https://reviews.freebsd.org/D2569
Reviewed by: araujo
Approved by: neel
MFC after: 1 week
Sponsored by: ScaleEngine Inc.
