Address two issues with current help file logic:
The existing condition prevents the common help file from being
installed when there are no additional help files defined. This results
in no loader.help on EFI platforms, for example.
Second, due to the fact that we build and install multiple loader types,
each successive install will clobber the previous loader.help. The
result is that we could lose type-specific commands, or possibly list
them in loaders that do not have such commands.
Instead, give each loader type a uniquely named help file. The EFI
loader will look for /boot/loader.help.efi, userboot will look for
/boot/loader.help.userboot, etc. The interpreter variant has no effect
on which help file is loaded.
This leaves the old /boot/loader.help unused.
Some credit for the final approach goes to Mathieu <sigsys@gmail.com>
for their version of the fix in https://reviews.freebsd.org/D22951.
PR: 267134
Reported by: Daniel O'Connor <darius@dons.net.au>
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28591
Pull together the nearly identical copies of set_currdev in i386,
userboot and efi. Other boot loaders have variances that might be fine
to use the common routine, or not. Since they are harder to test for me,
and ofw and uboot do handle these setting differently, leave them be for
now.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38005
Replace 4 identical copies of *_setcurrdev with gen_setcurrdev to avoid
having to create a 5th copy. uboot_setcurrdev is actually different and
needs to remain separate (even though it's quite similar).
Sponsored by: Netflix
Reviewed by: fuz@fuz.su, kevans
Differential Revision: https://reviews.freebsd.org/D38003
Pass in 'true' if you'd like to search this device's partitions or
'false' if you should just search the device. EFI and (in the future)
kboot have discrete partitions that aren't accessed via the full disk
device. Weird things happen if you try to search in these cases.
Sponsored by: Netflix
devinit() marches through all the devices, calling the inint routines if
any exist. Replace all the identical copies of this code.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37349
We no longer need to have to hand-code this for each boot loader since
devparse() handles them all with dv_parsedev().
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37342
Change the first argument to zfs_parsedev() to be a pointer to a struct
devdesc *. This now gets filled in with a malloc'd structure that's
returned to the caller that the caller is repsonsible for freeing. Most
nplaces in the tree passed in a malloc'd pointer anyway, and this moves
knowledge of zfs_devdesc more firmly into the zfs.c code.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37336
Change the first argument to disk_parsedev() to be a pointer to a struct
devdesc *. This now gets filled in with a malloc'd structure that's
returned to the caller that the caller is repsonsible for freeing. Most
places in the tree passed in a malloc'd pointer anyway, and this moves
knowledge of disk_devdesc more firmly into the disk.[ch] code.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37335
FreeBSD 4.x and earlier used the bi_bios_geom to get the geometry of the
device. Starting in 5.x, with the wdc -> ata rewrite, it was used only
in pc98 kernels to report geometry of the drives. It can be safely
removed as booting kernels this old is no longer supported. This saves
176 bytes in the BIOS loader.
Sponsored by: Netflix
Reviewed by: adrian, emaste
Differential Revision: https://reviews.freebsd.org/D36543
We set this value twice: once to 0 and once to the VA that has the name
of the kernel. The first store is redundant. In addition, these two
stores of 0 are also redundant. Since we never set them, they will
always be zero, even if we're called multiple times. This saves 21
bytes on BIOS loader.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36541
Use the efi's bi_copyenv to md_copyenv and place it in modinfo.c. Remove
all other nearly identical and efi's has the best error handling.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36574
md_copymodules, bi_copymdoules, bi_copymodules32 (x2) and
bi_copymodules64 (x2) are all the same routine... Replace them all with
md_copymodules. This saves about 800 bytes on i386 BIOS loader, which is
a nice bonus.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36572
Move all the MOD_xxx macros to this header. Each user of this interface
is currently required to define MOD_ALIGNMENT(l). modinfo was selected
because it sits inbetween modules and metadata and will make it easier
to migrate to new, shared intefaces.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36571
To further reduce the differences between the different MOD_xxx macros,
use MOD_ALIGN to do the proper alignment for the given use.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36570
This replaces the CALLBACK(copyin, ...) with a call to
archsw.arch_copyin which points to a function that does the
callback. More diff reduction for the multiple copies of these routines
in the tree.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36569
devformat produces the same output as userboot_fmtdev, so just use it to
reduce on the dependencies. In addition, we don't need to use the
incomplete struct userboot_devdesc type, we can use struct devdesc
instead (in fact, there's no userboot_devdesc defined anywhere).
Sponsored by: Netflix
Reviewed by: jhb (prior version)
Differential Revision: https://reviews.freebsd.org/D35925
All of the archsw fmtdev functions treat DEVT_DISK as a call to
disk_fmtdev. Set all disks' dv_fmtdev to disk_fmtdev so devformat
will return the same thing.
Sponsored by: Netflix
Reviewed by: tsoome (prior version)
Differential Revision: https://reviews.freebsd.org/D35917
dv_cleanup is specified almost everywhere. Use nullsys instead of NULL
to indicate 'do nothing'. Also, be consistent in trailing commas that
were missing before.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D35913
Detect the end of the disk condition. This may happpen when
disk image is truncated and the reads are addressing blocks past
image end.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35432
We don't need it for userboot, but it avoids issues with BIND_NOW, so
just provide it. time(3) isn't defined but ends up being provided by
libc linked into the host process, which is generally fine.
PR: 262920
Reviewed by: imp, jhb
MFC after: 3 days
Diferential Revision: https://reviews.freebsd.org/D34758
We never use 'dev' after fetching it from the varargs list. Skip the
whole bother of fetching it, or setting up the meachinery to fetch it.
Sponsored by: Netflix
All these files are the same, modulo one comment. Move them all into
common/gfx_fb_stub.c and adjust Makefiles accordingly.
Sponsored by: Netflix
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D33428
We want to keep our root file system open to preserve bcache segment
between file accesses, thus reducing physical disk IO.
Reviewed by: imp, allanjude, kevans (previous version)
Differential Revision: https://reviews.freebsd.org/D30848
MFC after: 1 month
The userboot/test program links against the default userspace libraries
(e.g. shared libgcc_s.so) that will be instrumented if WITH_ASAN is set.
All other programs link against libsa instead of libc and therefore can't
use the sanitizer runtime library. To fix the stand/ build with
sanitizers, we disable MK_ASAN/MK_UBSAN if -nostdlib is found in the
LDFLAGS (i.e. we are using libsa instead of libc).
Reviewed By: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D31047
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.
Export variables:
screen.height
screen.width
screen.depth
Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.
Probably something else I forgot...
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.
By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.
By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.
bootonce dataset name is recorded in boot pool labels, bootenv area.
in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.
bootonce and nextboot features are usable in both UEFI and BIOS boot.
To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).
At this time, only lua loader is updated.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25512
This is a change in preparation for stopping to use lorder.sh (D26044) and
instead assume that we have a linker newer than ~1990. Without lorder.sh
duplicates end up being passed to the linker when building .so files and this
can result in duplicate symbol definition errors.
There is one minor change: libcompiler_rt.a will no longer provide
gcc_personality_v0 and instead we now only have it in libgcc_eh.a/libgcc_s.so.
This matches GCC's behaviour.
Reviewed By: emaste, cem
Differential Revision: https://reviews.freebsd.org/D26042
We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our current simple textual string based approach with added
structured boot label PAD structure from OpenZFS.
Secondly, all nvlist details are moved to separate source file and
restructured a bit. This is done to provide base support to add nvlist
add/update feature in followup updates.
And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
libi386 and libsa.
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25324
These mappings are never visible to userspace as they get replaced when
the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
first place.
Reviewed by: alc, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24547
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 vectx API, computes the hash for verifying a file as it is read.
This avoids the overhead of reading files twice - once to verify, then
again to load.
For doing an install via loader, avoiding the need to rewind
large files is critical.
This API is only used for modules, kernel and mdimage as these are the
biggest files read by the loader.
The reduction in boot time depends on how expensive the I/O is
on any given platform. On a fast VM we see 6% improvement.
For install via loader the first file to be verified is likely to be the
kernel, so some of the prep work (finding manifest etc) done by
verify_file() needs to be factored so it can be reused for
vectx_open().
For missing or unrecognized fingerprint entries, we fail
in vectx_open() unless verifying is disabled.
Otherwise fingerprint check happens in vectx_close() and
since this API is only used for files which must be verified
(VE_MUST) we panic if we get an incorrect hash.
Reviewed by: imp,tsoome
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D23827
The values of the d_slice and d_partition fields of a disk_devdesc have a
few values with special meanings in the disk_open() routine. Through various
evolutions of the loader code over time, a d_partition value of -1 has
meant both "use the first ufs partition found in the bsd label" and "don't
open a bsd partition at all, open the raw slice."
This defines a new special value of -2 to mean open the raw slice, and it
gives symbolic names to all the special values used in d_slice and
d_partition, and adjusts all existing uses of those fields to use the new
constants.
The phab review for this timed out without being accepted, but I'm still
citing it below because there is useful commentary there.
Differential Revision: https://reviews.freebsd.org/D19262
Some of these files using <FOO>_DEBUG defined a DEBUG() macro to serve as a
debug-printf. -DDEBUG is useful to enable some debugging output across
multiple ELF/common parts, so switch the DEBUG-as-printf macros over to
something more like DPRINTF that is more commonly used for this kind of
thing and less likely to conflict.
userboot/elf64_freebsd debugging also assumed %llx for uint64; use PRIx64
instead.
MFC after: 1 week
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
Turns out there was a hidden dependency we hasn't counted upon. The
host load /boot/userboot.so to boot the VMs it runs. This means that
the change to lua meant suddently that nobody could run their older
VMs because LUA wasn't in 10.0, last month's HardenedBSD, 11.2 or
whatever. Even more than for the /boot/loader* binaries, we need a
good coexistance strategy for this. While that's being designed and
implemented, drop back to always 4th for userboot.so. This will fail
safe in all but the most extreme environments (but lua-only hacks
to .lua files won't be processes in VMs until we fix it).
Differential Review: https://reviews.freebsd.org/D16805
