Reports have come in that there's issue with powerpc and sparc64 since
we've switched to using -Oz / -Os. We don't strictly need them for
!x86, so be conservative about when we enable them.
Approved by: re@ (gjb)
Differential Revision: https://reviews.freebsd.org/D17016
This was disabled recently due to lack of support in KDB disassembler
and DTrace FBT provider. Support for 'C'-extension to both of these was
added, so we can now enable 'C'-extension.
This reduces size of the kernel important for low-end embedded devices,
and saves cache footprint for high perfomance machines.
Approved by: re (kib)
Sponsored by: DARPA, AFRL
/etc/security/audit_event to provide a list of audit event-number <->
name mappings. However, this occurs too late for anonymous tracing.
With this change, adding 'audit_event_load="YES"' to /boot/loader.conf
will cause the boot loader to preload the file, and then the kernel
audit code will parse it to register an initial set of audit event-number
<-> name mappings. Those mappings can later be updated by auditd(8) if
the configuration file changes.
Reviewed by: gnn, asomers, markj, allanjude
Discussed with: jhb
Approved by: re (kib)
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16589
The format for kernels is documented as being space-delimited, but
forthloader was more lenient on this and so people began to depend on it.
A later pass will be made to document all of the fun features that forthloader
allowed that may not be immediately obvious.
Reported by: mmacy
Approved by: re (kib)
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
Previously lualoader would remain silent, rather than printing
command_errmsg or noting that a command had failed or was not found.
Approved by: re (gjb)
Resetting to the default color scheme was done prior to reading the config.
This is bogus; colors may only be declined by the user with the
loader.conf(5) variable "loader_color", so such a request for no color will
not be completely honored as we reset to the default color scheme
unconditionally.
Approved by: re (rgrimes)
Lua has a few places where it allocates a large buffer on the stack. This
is normally fine, except there are a few places where there can be multiple
frames with this buffer. This can cause a stack overflow on some arm64 SoCs.
Fix this by allocating our own stack in loader.efi large enough for these
objects. The required size has been found by tracing how the stack pointer
changes in a virtual machine and found to be no larger than 50kB. A
larger stack is allocated to reduce the likelihood of overflow from future
changes.
Reviewed by: kevans
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D16886
Earlier changes setup a config.module_path variable that was populated upon
reading of loader.conf(5) and used for restoring module_path to pristine
condition if multiple kernels are attempted. This broke the ability to
override module_path at the loader prompt in case of emergency.
Approved by: re (rgrimes)
Generally straightforward enough; a copy of argv[1] was being made in
command_fdt_internal, solely used for a comparison within the
handler-search, then promptly leaked.
Reported by: ports gcc and clang's static analyzer
While loader.conf(5) suggests that all values should be quoted, reality is
that this was never strictly enforced and it is used. We already make some
concession to this in number values, which aren't strictly quoted either.
The compromise here is that multi-word values must be quoted. This lets
things like `foo_load=YES` work, while denying more complex expressions on
the right hand side. This likely catches the vast majority of current usage.
A bit of a kludge is needed to accomplish this since Lua regex doesn't
support branching. I had considered splitting up expressions and generating
the right-hand side of the expressions completely in config.parse, but
deemed this too large of an overhaul to take given the current timing. This
should be re-worked shortly after the thaw.
Reported by: royger
lualoader was not respecting the 'xen_kernel' environment variable, which
hints to the interpreter that it should load a Xen kernel prior to loading
any other kernel that might be specified. If a Xen kernel is specified and
we fail to load it, we should not proceed to boot.
Reported by: royger
Tested by: royger
manu found in the noted PR that overlays seemed to be clobbering the kenv
and killing the boot. Further inspection revealed that one can `fdt ls` at
the loader prompt for a successful boot, but autoboot breaks it.
In the autoboot case, first setup of FDT is happening in the middle of
bi_load, which triggers loading of the DTBO from /boot.
This is bad, bad, bad. Files in the loader are loaded somewhere in the
middle of the address space one after another. bi_load starts building the
needed kernel bootinfo immediately after the highest-addr loaded file. File
loads in the middle of bi_load suddenly clobber bootinfo and everything goes
off the rails.
The solution to this is to use take advantage of arch_autoload to setup FDT
in efiloader compiled with LOADER_FDT_SUPPORT. This matches how it works in
ubldr land, and is how it should have worked when overlay support was added
to efiloader since fdt_setup_fdtp now has the potential to load files
(courtesy of fdt_platform_load_dtb).
PR: 230804
Discussed with: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16858
As indicated by the comment, any fixups applied (which might include
overlays) can invalidate the previously located node by adding nodes or
setting/adding properties. The later fdt_setprop of fixup-applied property
would then fail because of the bad/wrong node offset.
This would have generally been harmless, but potentially caused multiple
applications of fixups and caused a little bit of bloat.
MFC after: 1 week
operation of "loader". The dramatic increase in size of
SPA_MAXBLOCKSIZE in r304321 causes the heap space to be exhausted,
so malloc() fails, ultimately leading to a memcpy() with a
destination of 0x0.
MFC after: 3 days
The current chain command does accept only device, allow also a file to be used,
such as /boot/pmbr or /boot/mbr (or stored third party MBR/VBR block).
Also fix file descriptor leak.
This includes some light rework to simplify the line parsing, as well. If
we hit a line match, we'll always either use the line and move on to the
next line, or we'll spew out malformed line errors.
We had multiple spots to output the error and set the status based on
whether we had a non-nil first capture group or failed EOL validation, but
it was always the same error. Light rework entails a small label jump to
skip error handling and elimination of 'found' local.
A couple of issues addressed:
1.) Modules with - in the name were not recognized as modules
2.) The module regex was repeated for each place a module name may appear
3.) The 'strip leading space' bits were repeated for each expression
4.) The trailing 'comment validation' stuff was repeated every expression
#4 still has some more work to be done. exec lines, for instance, don't
capture a 'value' -- there's only one capture pattern. This throws off the
'c' value that we match, so the trailing bits aren't *actually* being
validated. This isn't a new issue, though, so a future comit will address
this.
Remove a bunch of special cases for UEFI and serial consoles. We do
want to do curses and menu things here. This makes us match what we do
in FORTH, with the possible exception of boxes around menus.
Differential Revision: https://reviews.freebsd.org/D16816
Now that a complete set is written, save for one describing loader.lua,
install all of them. This was not previously done as they were written to
hopefully avoid confusion as bits and pieces of the overall system were
undocumented.
Uncovered while writing the documentation from this, we previously
explicitly fell back to orb or orbbw if an invalid or incompatible logodef
was selected -- in contrast to branddefs, which have an exported variable
that one can whip up a quick local.lua to override in a safe manner that
works regardless of whether or not loader.conf(5) successfully loads.
These are less controversial than the others, thus done in a separate
commit. These are all used internally and ways to override are provided via
soon-to-be-documented API or loader.conf(5) variables.
Ideally, all of the functionality to revamp the loader screen has associated
APIs that are flexible enough that third-party scripts wouldn't need to
override these.
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
After years in the making, lualoader is ready to make its debut. Both
flavors of loader are still built by default, and may be installed as
/boot/loader or /boot/loader.efi as appropriate either by manually creating
hard links or using LOADER_DEFAULT_INTERP as documented in build(7).
Discussed with: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16795
Compiling FreeBSD/i386 with modern GCC triggers warnings for various
places that convert 64-bit EFI_ADDRs to pointers and vice versa.
- Cast pointers to uintptr_t rather than to uint64_t when assigning
to a 64-bit integer.
- Cast 64-bit integers to uintptr_t before a cast to a pointer.
Reviewed by: kevans
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16586
BD_SUPPORT_FRAGS is preprocessor knob to allow partial reads in bioscd/biosdisk
level. However, we already have support for partial reads in bcache, and there
is no need to have duplication via preprocessor controls.
Note that bioscd/biosdisk interface is assumed to perform IO in 512B blocks,
so the only translation we have to do is 512 <-> native block size.
Differential Revision: https://reviews.freebsd.org/D16600
While we're not super size constrained, the x86 BIOS /boot/loader has
to be less than about 520k-530k to be reliable. The LUA loader is at
this size today. -Oz saves 15-20% on the size, keeping us safely small
enough (comparable to where we were with the 4th loader). This will
also help with sjg's work on bringing in bearssl, though we may again
be looking for space in the LUA loader.
Size table for clang 6.0.0:
default -O1 -Os -Oz
4th 442368 417792 389120 376832
lua 524288 479232 446464 430080
Tested by: kevans91@ (ubldr on armv7), dhw@ (loader on amdy64)
Differential Revision: https://reviews.freebsd.org/D16724
Create loader_{4th,lua,simp}{,.efi}. All of these are installed by
default. Create LOADER_DEFAULT_INTERP to specify the default
interpreter when no other is specified. LOADER_INTERP is the current
interpreter language building. Turn building of lua on by default to
match 4th. simploader is a simplified loader build w/o any interpreter
language (but with a simple loader). This is the historic behavir you
got with WITHOUT_FORTH. Make a hard link to the default loader. This
has to be a hard link rather than the more desirable soft link because
older zfsboot blocks don't support symlinks.
RelNotes: Yes
Differential Revision: https://reviews.freebsd.org/D16705
after opening the console, replacing init as PID 1.
From the user point of view, it makes it possible to run eg the
shell as PID 1, using 'set init_exec=/bin/sh' at the loader(8)
prompt.
Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16625
It was possible in some rare circumstances for ngets to behave terribly with
bhyveload and some form of redirecting user input over a pipe.
PR: 198706
Submitted by: Ivan Krivonos <int0dster@gmail.com>
MFC after: 1 week
gptboot was broken when r316078 added the LOADER_GELI_SUPPORT #ifdef to
not pass geliargs via __exec. KARGS_FLAGS_EXTARG must not be used if we're
not going to pass an additional argument to __exec.
PR: 228151
Submitted by: guyyur@gmail.com
MFC after: 1 week
Since bd_open() does early increment for reference counter and bcache
allocation, it also should undo those in case of the error.
Also remove unused variables rdev, g_err.
On a FreeNAS mini XL, with geli encrypted drives the loader crashed in
geli_read().
When we iterate over the list of disks and allocate the zfsdsk structures we
don’t zero out the gdev pointer. In one case that resulted in geli_read()
(called on the bogus pointer) dividing by zero.
Use calloc() to ensure the zfsdsk structure is always zeroed, so the pointer is
initialised to NULL. As a side benefit it gets rid of one #ifdef
LOADER_GELI_SUPPORT.
number and CHS based number. However, on some systems, BIOS would
report 0 in CHS fields, making the system to think there is 0 sectors.
Add a check before comparing the calculated total with bd_sectors.
Reviewed by: tsoome, cy
Differential Revision: https://reviews.freebsd.org/D16577
efi-autoresizecons is currently executed for every boot. If it fails, we
risk failing the boot, and we really shouldn't do that unless we absolutely
must.
Not being able to locate GOP or UGA is not a significant enough failure to
kill the boot. We always have the option to fall back to resizing ConOut to
a higher text mode resolution (if available), so do that.
This was detected by Doug [1] while attempting a bhyve + UEFI + PXE boot.
This patch was effectively also submitted by Doug, but I expanded the
comment he had originally sent me a little bit to indicate why this is an OK
idea.
Reported by: Doug Ambrisko <ambrisko@ambrisko.com> [1]
number of sectors reported through the BIOS. Cylinders * heads *
sectors may not necessarily be equal to the total number of sectors
reported through int13h function 48h.
An example of this is when a Mediasonic HD3-U2B PATA to USB enclosure
with a 80 GB disk is attached. Loader hangs at line 506 of
stand/i386/libi386/biosdisk.c while attempting to read sectors beyond
the end of the disk, sector 156906855. I discovered that the Mediasonic
enclosure was reporting the disk with 9767 cylinders, 255 heads, 63
sectors/track. That's 156906855 sectors. However camcontrol and
Windows 10 both report report the disk having 156301488 sectors, not
the calculated value. At line 280 biosdisk.c sets the sectors to the
higher of either bd->bd_sectors or the total calculated at line 276
(156906855) instead of the lower and correct value of 156301488 reported
by int 13h 48h.
This was tested on all three of my Mediasonic HD3-U2B PATA to USB
enclosures.
Instead of using the higher of bd_sectors (returned by int13h) or the
calculated value, this patch uses the lower and safer of the values.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D16577
If there are no block devices, there is no need to printout
error (ENOENT).
In case of netboot, our image path has no block device, no need to make
noise about it.
1MB was leaving very little margin in some of the worse-case scenarios with
lualoader. 2MB is still low enough that we shouldn't have any problems with
UBoot-supported boards.
MFC after: 1 week
The latter matches the rest of the tree better [0]. The UPDATING entry has
been updated to reflect this, and the new tunable is now documented in
loader(8) [1].
Reported by: imp [0], Shawn Webb [1]
Note when we've found a 8250 PNP node. Only try to set hw.uart.console
if we see one (otherwise ignore serial hints). The 8250 is the only
one known to have I/O ports, so limit the guessing to when we've
positively seen one. And limit this to x86 since that's the only
platform where we have I/O ports. Otherwise, we'd set the serial port
to something crazy for the platform and fall off the cliff early in
boot.
Differential Revision: https://reviews.freebsd.org/D16463
Add some verbose debugging information to the loader's new
choices. I'll remove these / put them behind a DEBUG define at a later
time. This is to give additional information if there's any dangling
edge cases not contemplated by the code. r336789 had most of this
change, but had the wrong commit message. This refines it slightly.
nodes. These show up in default entries on SuperMicro motherboards and
elsewhere. Before, we couldn't find a block device associated with the
device path and return BAD_CHOICE which was an instant
failure. However, a VendHw node isn't specifc, so when we don't find a
media path, return NOT_SPECIFIC so that the rest of the algorithms
work.
Sponsored by: Netflix.
It works excellent, but KDB disassembler and DTrace FBT provider for
RISC-V do lack support for it. They currently handle 4-byte instructions
only, while C-compressed ISA extension introduces 2-byte instructions
freely mixing them together.
So disable it for now.
Reviewed by: markj@
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16436
loading.
If we are booting in a conforming UEFI Boot Manager Environment, then
use the BootCurrent variable to find the BootXXXX we're using. Once we
find that, then if it contains more than one EFI_DEVICE_PATH in its
what to boot section, try to use the last one as the kernel to
load. This will also set the default root partition as well. If
there's only one path, or if there's an error along the way, assume
that nothing specific was specified and revert to the old
algorithm. If something was specified, but not found, then fail the
boot. Otherwise you that, specific thing. On FreeBSD, this can be set
using efibootmgr -l <loader> -k <kernel>. We try a few variations of
kernel to cope with the fact that UEFI comes from a DOS world where
paths might be upper case and/or contain back-slashes.
Note: In an ideal world, we'd work out where we are in chain loading
by looking at the passed-in image handle and doing name
matching. However, that's unreliable since at least boot1.efi booted
images don't have that, hence the assumption that loader.efi needs to
load the last thing on the list, if possible.
The reason we fail for something specific is so that we can fully
participate in the UEFI Boot Manager Protocol and fail over to the
next item in the list of BootOrder choices when something goes wrong
at this stage.
This implements was was talked about in freebsd-arch@ last year
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3576+0+archive/2017/freebsd-arch/20171022.freebsd-arch
and documented in full (after changed resulting from the discussion) in
https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#
although one or two minor details may have been modified in this
implementation to make it work, and the ZFS MEDIA PATH extension isn't
implemented. This does not yet move things to ESP:\efi\freebsd\loader.efi.
RelNotes: Yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16403
Lookup a block device by it's device path. We use a 'loose' lookup
whereby we scan forward to the first Media Path portion of the device
path, then look at all our handles for one whose first Media Path
matches. This will also work if the device path pointed to has a
following file path (or paths) as that's ignored. It assumes that
there's only one media path node that describes the entire device,
which is true as of the latest UEFI spec (2.7 Errata A) as far as I've
been able to determine.
Sponsored by: Netflix
Returns true if the first node pointed to by devpath1 is identical to
the first node pointed to by devpath2, with care taken to not read
past the end of the valid parts of either devpath1 or
devpath2. Otherwise, returns false.
Sponsored by: Netflix
Takes a generic device path as its input. Scans through it to find the
first media_path node in it and returns a pointer to it. If none is
found, NULL is returned.
Sponsored by: Netflix
line args. I had thought console would be NULL, but it's efi. Set it
to efi (as a clue) before we initialize the console, then test it to
see if it changed on the command line to do the automatic
override. This gets my serial console back.
zfsloader as a hard link. While newer ones do, the whole point of the
link was to transition to the new world order smoothly. A hard link is
less flexible, but it works and will result in fewer bumps. Adjust
UPDATING entry to match.
Remove all cross references to zfsloader.8 and /boot/zfsloader.
Move ZFS specific info into loader.8.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16361
We no longer really need a separate zfsloader. It was useful when we
were first supporting ZFS and had limited ability to properly boot off
of ZFS without the special boot loader. Now that the boot loader has
matured, go the way loader.efi pioneered and just build one
binary. Change the name of the loader to load in the secondary boot
blocks to be just /boot/loader. Provide a symbolic link from zfsloader
to loader so people who have not upgraded their boot blocks are not
affected. This has the happy benefit of making coexistence easier as
well (fewer binaries in the matrix).
Discussed with: allanjude@, kevans@
RelNotes: Yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16361
Setting rootdev in the enviornment should specify things
completely. If it is set, then have it override everything else.
PR: 229770
Differential Review: https://reviews.freebsd.org/D16322
up serial output. Setting the cursor position after every character is
inefficient, and causes all lines to be over-printed in the serial
console for the boot loader. Allow the terminal to do the emulation.
This isn't completely perfect when the size of the terminal attached
to the serial port isn't the same as 80x25 to match the viedoe console
(or whatever the video console is). While imperfect still, these
changes make it much better.
This makes the serial port useful with UEFI.
Differential Revision: https://reviews.freebsd.org/D16309
o Fix the parsing of the device path. a last minute change terminated
it too soon.
o Kill setting LINES. We don't need to do it, and even if we did hard
coding it to 24 is wrong.
o Now that the console is working again for the loader, adjust the
printfs to be more in line with other platforms.
note that r336270's commit message was slightly incorrect. It changed
the default setting of the console to honor the ConOut
variable. Overrides via the command line are still possible, and we
use the devices in ConOut to set the proper console. If, for example,
serial cosnole is specified, we'll set console to "efi" if ConOut has
a serial port list and to either "efi comconsole" or "comconsole efi"
if not depending on whether -D or -D -h was specified.
RelNotes: Yes
Sponsored by: Netflix
For server machines, ComOut is set to the set of devices that the efi
console suppots. Parse it to see if we have serial, video or both.
Make that take precidence over the command line args. boot1.efi parses
them, but loader.efi doesn't. It's not clear where to read boot.conf
from, so we don't do that. The command line args can still be set via
efibootmgr, which is more inline with the UEFI boot manager to replace
that. These args are typically used only to set serial vs video and
the com speed line. We can infer that from ComOut, so do so.
Remember the com speed and hw.uart.console to match.
RelNotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15917
This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.
Relnotes: yes
Sponsored by: Microchip Technology Inc
Differential Revision: https://reviews.freebsd.org/D15743
to it being a common name elsewhere. Rename the old kzip one
to subr_inflate.c.
This actually fixes the build issues on sparc64 that my inclusion of
.PATH ${SYSDIR}/kern created in r336244, so also revert the broken
workaround I committed in r336249.
This slipped passed me because apparently, I never did a clean build.
Eliminate 4 of the copies of the arg parsing in /boot/laoder
by using boot_parse_cmdline.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16205
boot_parse_arg to parse a single arg
boot_parse_cmdline to parse a command line string
boot_parse_args to parse all the args in a vector
boot_howto_to_env Convert howto bits to env vars
boot_env_to_howto Return howto mask mased on what's set in the environment.
All these routines return an int that's the bitmask of the args
translated to RB_* flags. As a special case, the 'S' flag sets the
comconsole_speed env var. Any arg that looks like a=b will set the env
key 'a' to value 'b'. If =b is omitted, 'a' is set to '1'. This
should help us reduce the number of redundant copies of these routines
in the tree. It should also give a more uniform experience between
platforms.
Also, invent a new flag RB_PROBE that's set when 'P' is parsed. On
x86 + BIOS, this means 'probe for the keyboard, and if it's not there
set both RB_MULTIPLE and RB_SERIAL (which means show the output on
both video and serial consoles, but make serial primary). Others it
may be some similar concept of probing, but it's loader dependent
what, exactly, it means.
These routines are suitable for /boot/loader and/or the kernel,
though they may not be suitable for the tightly hand-rolled-for-space
environments like boot2.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16205
While ../zfs/libzfs.h mostly works, there are a few situations where
it does not. Eliminate the problem by using plain libzfs.h, like we do
for ufs support. This fixes the weird cases, and is easier to
understand. It also follows the general style convetion of avoiding
../ in #includes.
Move the libzfs stuff into libsa. There's no need for it to be a
separate library. The separate library adds to the issues of build
ordering that we see from time to time. Move the filesystem support
into libsa, like all the other filesystem support rather than making
zfs the odd-duck out.
Discussed with: allanjude@
U-Boot setup a few variables :
- fdt_addr which is the board static dtb (most of the time loaded before
u-boot or coming from some hardware like a ROM)
- fdt_addr_r which is a location in RAM that holds the DTB loaded by
u-boot or before u-boot
In the case of u-boot + rpi firmware the DTB is loaded in RAM but the location
still end up in the fdt_addr variable and the fdt_addr_r variable exist.
Change the behavior so we test that a DTB exists for every possible variable :
- fdt_addr_r is checked first as if u-boot needed to modify it the
correct DTB will live there.
- fdt_addr is checked second as if we run on a hardware with DTB in ROM
it means that we what/need to run that
- fdtaddr looks like a FreeBSD-ism but since I'm not sure leave it.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D16101
Previously the code cut those fields on second colon, that prevented
boot from boot environments with colon in their names. This change
moves the limitation from dev field to path, which is empty by default.
Reviewed by: allanjude, tsoome
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D16068
If a disk is of an oddball size, like the 200mb + 512b used in rootgen.sh,
when disk_open() is called on a GELI encrypted partition, attempts to read
the partition table fail, as they pass through the decryption process which
turns the already plaintext data into jibberish.
When reading the partition table, always pass a slice and partition setting
of -1, and an offset of 0. Setting the slice to -1 prevents a false
positive when checking the slice against the cache of GELI encrypted
slices.
Reviewed by: imp, ian
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15847
While in base we use it as a boolean (of the wrong spelling), there's
at least one out of tree user that needs it to be int since priorirty
is a small int, not a 0/1. In deference to the time it's wasted me and
my team, push this up into FreeBSD for whatever short life boot1 may
have in the tree.
SVN r280384 updated the maximum password length from 16 bytes to 255. The
manual was not updated to reflect this. Found while working on kern/207069.
MFC after: 3 days
X-MFC-to: stable/11 stable/10
Sponsored by: Smule, Inc.
This was causing issues for people booting.
I will likely bring this back as an optional feature, similar to
boot0sio, like gptboot-serial or something.
PR: 221526
Reported by: O. Hartmann <ohartmann@walstatt.org>, Thomas Laus <lausts@acm.org>
Reduce by 1 the number of crazy libraries we need in stand by moving
geli into libsa (where architecturally it belonged all along). This
just moves things around without any code changes.
Normally the serial console is not enabled until /boot.config is read and
we know how the serial console should be configured. Initialize the
consoles early in 'dual' mode (serial & keyboard) with a default serial
rate of 115200. Then serial is re-initialized once the disk is decrypted
and the /boot.config file can be read.
This allows the GELIBoot passphrase to be provided via the serial console.
PR: 221526
Requested by: many
Reviewed by: imp
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15862
The GELI boot code rounds reads up to 4k, since the encrypted sectors are
4k, and must be decrypted as a unit. With oddball sized disks (almost
always virtual), this can lead to reading past the end of the disk.
Reviewed by: imp, tsoome
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15844
`rdev` and `disk` serve the same purpose, read the partition table without
the `d_offset` or `d_slice` set, so the read is relative to the start of
the disk. Reuse the already initialized `disk` instead of making another
copy later.
Sponsored by: Klara Systems
The wrong condition is used when evaluating the return of disk_ioctl()
This results in reaching the 'We should not get here' branch in most casts
Reviewed by: imp
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15839
table if we're just going to ignore it on arm, so expand, slightly,
the reach of the ifdef. Move the buffer to the inner block so we
don't have a separate #ifdef far away from these lines.
The issue on arm is that smbios_detect does unaligned accesses, which
in the u-boot implementing EFI context causes a crash.
is. We tell the ZFS code now, and it checks rather than having a
callback to do the checks.
This will allow us to have a more graceful fallback code. In the
future, it's anticipated that we may fallback to a more global search
(or implement a command to do so) when reqeusted by the user, or we
detect a violation of the UEFI Boot Manager protocol severe enough to
warrant this backstop. For now, it just allows us to get rid of img as
a global.
Sponsored by: Netflix
To recap the problem: with a black-on-white xterm, the menu draws terribly.
Ideally, we would try our best for a white-on-black context for the menu
since graphics and whatnot might not be tested for other setups and there's
no reasonable way to sample the terminal at this point for the used color
scheme.
This commit attempts to address that further in two ways:
- Instead of issuing CSI bg/fg resets (CSI 39m and CSI 49m respectively for
"default"), issue CSI bg/fg escape sequences for our expected color scheme
- Reset to *our* default color scheme before we even attempt to load the
local module, so that we personally don't have any earlier text with the
console default color scheme.
Reported by: emaste (again)
dteske@, I believe, had originally pointed out that lualoader failed to
allow logo-*.lua for new logos to be added. When correcting this mistake, I
failed to do the same for brands.
Correct the sub-mistake: creating new brands is almost identical to creating
new logos, except one must use `drawer.addBrand` and 'graphic' is the only
valid key for a branddef at the moment.
While here, I've added `drawer.default_brand` to be set to name of brand to
be used (e.g. 'fbsd', project default).
Eventually this whole goolash will be documented.
Reported by: kmoore, iXsystems
We support both of the following cases of substitution:
bar="y"
foo="${bar}"
foo="$bar"
The latter substitution syntax is, of course, not recommended- all
punctuation must be considered potential variable names, and we do not go
through the effort of searching the different combinations of, for instance,
"$x.y.z" to determine if the variable is $x, $x.y, or $x.y.z.
This is not officially documented as supported, but it has worked in
forthloader for what is most likely a long time as `evaluate` is used to
process the right hand side of the assignment.
loader.conf(5) documents loader_conf_files to mean "additional configuration
files to be processed right after the present file." However, lualoader
ignored loader_conf_files after processing /boot/defaults/loader.conf.
Rewrite these bits to process loader_conf_files after each loaded file.
e.g. boot_mute, boot_single, boot_verbose, and friends; we checked for these
in multiple places, consolidate into common/ and allow a setting of "NO" for
any of these to turn them off. This allows systems with multiple
loader.conf(5) or loader.conf(5) overlay systems to easily turn off
variables in later processed files by setting it to NO.
Reported by: Nick Wolff @ iXsystems
Reviewed by: imp
- jhb implemented UFS write support a little over 16 years ago.
- Update the library name while we're here.
Reviewed by: jhb, rpokala
Differential Revision: https://reviews.freebsd.org/D14476
This will not be executed on reload, though later work could allow for that.
It's intended/expected that later work won't generally need to happen on
every config load, just once (for, e.g., menu initialization) or just when
config is reloaded but not upon the initial load.
r330809 replaced duplication of devdesc struct fields with an embedded copy
of the devdesc struct, to avoid fragility. That means all the scattered
comments indicating that structs must match are no longer valid. Likewise
asserts that attempted to mitigate some of the old fragility.
Reviewed by: imp@
This makes them compatible with the C standard signatures, avoiding
spurious mismatch errors in the places where the oddball requirements
of standalone code end up putting two declarations of the same function
in play.
* Make autoboot() a static function in stand/common/boot.c, so it does
not shadow local variables in gptboot.c and zfsboot.c.
* Remove -Winline from the Makefiles for gptboot, gptzfsboot and
zfsboot, as gcc will always fail to inline some functions, and there
is nothing we can do about it.
* For gcc <= 4.2.1, silence -Wuninitialized for isoboot, as it produces
a false positive warning.
* Remove deprecated and unnecessary -mcpu=i386 flag from stand/defs.mk,
as there is already a -march=i386 flag further in the file.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D15628
than doing weird type-punning that happened to work because the size
was right. We copied a zfs devdesc into a disk_devdesc and then after
passing through a NULL pointer reinterpreted it as a
zfs_devdesc. Instead, pass the base devdesc around and 'upcase' when
we know the types are right.
This has the happy side effect of fixing a gcc warning about bad
type punning.
Differential Revision: https://reviews.freebsd.org/D15629
If the check for a UFS partition at offset 0 on the disk fails, check
to see if there's a BSD disklabel at block 1 (standard) or at offset
512 (install images assume 512 sector size). If found, probe for UFS
on the 'a' partition.
This fixes UEFI booting images from a BSD labeled MBR slice when the
'a' partiton isn't at offset 0. This is a stop-gap fix since we plan
on removing boot1.efi in FreeBSD 12. We can't easily do that for 11.2,
however, hence the short MFC window.
Tested by: emaste@
MFC After: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15598
r329190; sparc64 kernels are always 64-bit but with that revision
in place, the loader was treating them as 32-bit ones.
- In order to reduce the likelihood of this kind of breakage in the
future, #ifdef out md_load() on sparc64 and make md_load_dual() -
which is currently local to metadata.c anyway - static.
- Make md_getboothowto() - also local to metadata.c - static.
- Get rid of the unused DTB pointer on sparc64.
Perhaps RB_MUTE could mute user startup (rc) output as well, but right
now it mutes only kernel console output, so make the documentation match
reality.
PR: 228193
Sponsored by: The FreeBSD Foundation
Even though we don't use it, it appears something else requires it to
be != 0 to work. This breaks tftp boot in loader.efi, so revert until
that can be sorted out.
If the 'n' flag is provided the provided key number will be used to
decrypt device. This can be used combined with dryrun to verify if the key
is set correctly. This can be also used to determine which key slot we want to
change on already attached device.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D15309
Contrary to what the message says, this is not only executed in an EFI
context- it provides functions for use in an EFI environment. I don't think
there's much reason to broadcast this fact when we haven't in the past, so
just remove it.
Reported by: emaste (a while ago), cperciva
r332090 added a LINKER_TYPE test to add the --no-rosegment flag when
linking the i386 loader components with lld. Instead, introduce a
general mechanism for setting LDFLAGS for a specific linker type,
and use it for --no-rosegment.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14998
- We should be setting a known graphics mode on conout, but we aren't.
- We shouldn't be setting gop mode if we didn't find a good resolution to
set, but we were. This made efi_max_resolution=1x1 effectively worthless,
since it would always set gop mode 0 if nothing else.
Harry Schmalzbauer reports that some firmware, in his experience, trips
over the ESP we install due to the volume label. It has been theorized that
this is due to some confusion with the label and the path on the ESP to
boot1.efi.
Regardless, Harry found that renaming the label seems to fix it.
PR: 214282
MFC after: 3 days
Since we do free subtopic and desc in help_getnext(), we need to set them also
NULL, so we make sure we dont get double free().
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D15082
With r328289 we attempt to make sure we free the resources allocated in
help_getnext(), however, it is possible that we get no resources allocated
and help_getnext() will return early.
Make sure we have pointers set to NULL early in help_getnext().
Reported by: Andy Fiddaman
While Arcnet has some continued deployment in industrial controls, the
lack of drivers for any of the PCI, USB, or PCIe NICs on the market
suggests such users aren't running FreeBSD.
Evidence in the PR database suggests that the cm(4) driver (our sole
Arcnet NIC) was broken in 5.0 and has not worked since.
PR: 182297
Reviewed by: jhibbits, vangyzen
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15057
Refactor the currdev setting to find the device we booted from. Limit
searching when we don't already have a reasonable currdev from that to
the same device only. Search a little harder for ZFS volumes as that's
needed for loader.efi to live on an ESP.
Sponsored by: Netflix
Differential Review: https://reviews.freebsd.org/D13784
There's problems with them. The order of efi stuff isn't quite right,
and there's various problems. Revert until thos problems can be fixed.
Reviewed by: kevans@
Earlier efforts to stop loading the menu broke the ability to skip the menu
with, e.g., beastie_disable in loader.conf(5) as it was decided before
configuration was read.
Defer bringing in the menu module until we've loaded configuration so that
we can make a more informed decision on whether the menu should be skipped
or not.
btxld does not correctly handle input with other than 2 PT_LOAD
segments. Passing --no-rosegment lets lld produce output eqivalent to
ld.bfd: 2 PT_LOAD segments and no PT_GNU_RELRO.
PR: 225775
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14956
When booted via isoboot(8) loader will be handed a disk that simply contains
an ISO9660 image. Currently this confuses it greatly. Teach it how to spot
that it's in this situation and that ISO9660 has one "partition" covering
the whole disk.
Reviewed by: imp
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14915
This is part of a project for adding the ability to create hybrid CD/USB boot
images. In the BIOS case when booting from something that isn't a CD we need
some extra boot code to actually find our next stage (loader) within an
ISO9660 filesystem. This code will reside in a GPT partition (similar to
gptboot(8) from which it is derived) and looks for /boot/loader in an
ISO9660 filesystem on the image.
Reviewed by: imp
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14914
Effectively disabling the mode changing bits in the loader. No matter which
way we go with it, it seems to be wrong- either the firmware doesn't change
the resolution and reports the resolution we requested, or the firmware
changes the resolution and doesn't report the resolution we requested. It
some cases, it does the right thing, but the bad cases outweight those.
Interested individuals can still set efi_max_resolution to 1080p or whatnot
in loader.conf(5) to restore the new behavior, but the new behavior does not
work out well for many cases.
Discussed with: imp
This commit splits all of the logodefs/graphics out into their own own files
and provides a method for these files to register their logodefs with the
drawer. Graphics are now loaded on demand if they don't exist in the current
set of logodefs.
The drawer module becomes a little easier to navigate through without all of
the graphics mixed in. It's also easy to do one-off graphics like the
9.2 Die Hard tribute by dteske@ without adding even more to our memory
requirements.
- No need for a 'goto' when our entire loop body is then wrapped in a
conditional.
- No need to leave commented out prints laying around
- If an expression is clearly going to be either nil or an expression that
isn't likely to be a boolean, we might as well use `or` to specify a
default value for the expression. e.g. `loader.getenv(...) or "no"`
The previous iteration of this assumed that {module}_load was set. In the
old world order of default loader.conf(5), this was probably a safe
assumption given that we had almost every module explicitly not-loaded in
it.
In the new world order, this is no longer the case, so one could delete a
_load line inadvertently while leaving a _name, _type, _flags, _before,
_after, or _error. This would have caused a confusing Lua error and borked
module loading.
If the network interface or the uefi implementation do not support the
ReceiveFilter interface do not return only and just print a message.
U-Boot doesn't support is and likely never will. Also even if this fails
it doesn't mean that network in EFI isn't supported.
hrs@ and kuriyama@ have found that on some HP BIOS, a system will fail to
boot immediately after installation with the claim that it can't work out
which disk they are booting from.
They tracked it down to a buffer overrun, and found that it could be
alleviated by doing a dummy read before-hand.
Submitted by: kuriyama
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14341
zfsloader(8) fails to probe a slice containing ZFS pool if its second sector
contains traces of BSD label (DISKMAGIC == 0x82564557).
Fix manual page to show working example erasing such traces.
PR: 226714
Approved by: avg (mentor)
MFC after: 3 days
It was previously only printed, but we do actually want to raise it as a
full blown error so that things don't look OK when they've actually gone
wrong.
The second parameter to error, level, is set to 2 here so that the error
message reflects the position of the try_include caller, rather than the
try_include itself. Example:
LUA ERROR: /boot/lua/loader.lua:46: /boot/lua/local.lua:1: attempt to call a
nil value (global 'cxcint').
This provides a way to optionally include a module without having to wrap it
in filesystem checks. try_include is a little more robust, using the lua
search path instead of forcing us to explicitly consider all of the places
we could want to include a module. Errors are still generally raised from
trying to load the module, but ENOENT will not get raised unless we're doing
a verbose load.
This will also be used to split out logo/brand graphics into their own files
so that we can safely scale up the number of graphics included without
worrying about the extra memory consumption- opting to lazily load graphics
instead.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D14658
UGA does not have the same kind of mode enumeration that GOP does. Implement
it instead as a call to text_autoresize so that firmwares with only UGA
present still get some kind of autoresizing behavior.
While here, rename a typo'd "gop" to "uga", although it will remain unused
for the time being.
This pertains exclusively to the set/restore functionality that we offer,
where any changes made by loader.conf previously will be effectively removed
upon reload of the configuration. We don't currently have a need to export
these, so don't bother.
Not all systems use efifb; pull hw.vga.textmode and choose a good console
mode instead if it's set to something non-zero. This is basically a revival
of the code that used to live in boot1, but instead rebased onto this
different way of doing mode selection in loader.efi.
Interestingly enough, the regression that was previously introduced where
GOP would not reflect the console setting does not seem to exist when
console mode selection is done here. I've not done any investigation as to
why this is the case. Nevertheless, boot1.efi is still not the best place to
do mode selection.
Default the max resolution to 1080p, we'll accept Width x Height
specifications along with the following presets:
- 480p
- 720p
- 1080p
- 2160p or 4k
- 5k
PR: 224825
Differential Revision: https://reviews.freebsd.org/D14801
I thought I tested this scenario, but clearly I failed to. =(
BIOS boots won't have efi-autoresizecons, so trying to use it as a forth
word fails during include. Use evaluate on "efi-autoresizecons" as a string
instead to move any potential errors to runtime- safely after we've already
checked that we're booting UEFI.
Pointy hat to: me
Reported by: cy
r331321 delegated autoresizing to an efi-autoresizecons command that
currently is expected to be done in forth/lua prior to drawing anything
useful.
Add the Forth version of the lua addition in r331321, hook efi.4th up to be
installed.
efiboot? was written by dteske@; anything outside of that may be blamed on
me.
boot1 is too early to be deciding a good resolution. Console modes don't map
cleanly/predictably to actual screen resolutions, and GOP does not reflect
the actual screen resolution after a console mode change. Rip it out.
Add an efi-autoresizecons command to loader to choose an optimal screen
resolution based on the current environment. We'll explicitly execute this
later, preferably before we draw anything of value but after we load config
and pick up any tunables we may need to decide where we're going.
This method also allows us to actually pass the correct framebuffer
information on to the kernel.
UGA autoresizing is not implemented because it doesn't have the kind of mode
enumeration that GOP does. If an interested person with relevant hardware
could get in contact, we can take a look at implementing UGA autoresize.
This effectively "fixes" the breakage caused by r327058, but doesn't
actually set the resolution correctly until the interpreter calls
efi-autoresizcons. The lualoader version of this has been included for
reference; the forth equivalent will follow.
Reviewed by: imp (with some hestitation), manu
Differential Revision: https://reviews.freebsd.org/D14788
In the original lualoader project, 'escapef' and 'escapeb' were chosen for
'escape fg' and 'escape bg'. We've carried on this naming convention, and as
our use of attributes grow the likeliness of 'escapeb'/'resetb' being
confused upon glance for 'escape bold'/'reset bold' increases.
Fix this by renaming these four functions to {escape,reset}{fg,bg} rather
than {escape,reset}{f,b} for clarity.
Reported by: dteske
See: comments in the hook module about intended usage, as well as the
introduced use for config.reloaded.
Use the newly introduced hook module to define a "config.reloaded" hook.
This is currently used to register core's clearKernelCache as a reload hook
to avoid a circular dependency and fix this functionality- it didn't
actually work out, and it isn't immediately obvious how it slipped into src.
Other hook types will be introduced into the core lualoader as useful hook
points are identified.
Previously, we sent a CSI 0m sequence to reset attributes, which also reset
the color scheme if the terminal defaults didn't match what we're expecting.
Go all-in and reset the color scheme, too, just in case.
Reported by: emaste
The former is fairly vague; these are FDT overlays to be applied to the
running system, so /boot/dtb is a sensible location to put it without
cluttering up /boot/dtb even further if desired.
The console may have been set for different colors before lualoader kicks
in; notably, a black-on-white color scheme is not necessarily what we're
expecting.
While here, make color.default() a composition of color.escape() instead of
rewriting the escape sequence to make it more obvious what it's achieving: a
white-on-black color scheme with no attributes set.
Reported by: emaste, whose eyes may rest easily
Followup to r313780. Also prefix ext2's and nandfs's versions with
EXT2_ and NANDFS_.
Reported by: kib
Reviewed by: kib, mckusick
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D9623
lualoader in itself only uses another ~200K, but there seems to be no reason
not to bump it a little higher to give us some more wiggle room.
With this, I can boot using a menu-enabled lualoader, no problem and
reasonably fast. Some heap usage datapoints from the review:
forthloader, no menus, kernel loaded:
heap base at 0x1203d5b0, top at 0x1208e000, used 330320
lualoader, no menus, kernel loaded:
heap base at 0x42050028, top at 0x420ab000, used 372696
lualoader, menus, kernel loaded:
heap base at 0x42050028, top at 0x420d5000, used 544728
Since then, the no menu case for lualoader should have decreased slightly as
I've made some changes to make sure that it no longer loads any of th emenu
bits with beastie disabled.
While here, split heap size out into a HEAP_SIZE macro.
Reviewed by: ian, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14471
This fixes a problem encountered on the Lenovo Thinkpad X220/Yoga 11e where
runtime services would try to inexplicably jump to other parts of memory
where it shouldn't be when attempting to enumerate EFI vars, causing a
panic.
The virtual mapping is enabled by default and can be disabled by setting
efi_disable_vmap in loader.conf(5).
Reviewed by: kib (earlier version)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D14677
A foolish consistency is the hobgoblin of little minds, adored by
little statesmen and philosophers and divines. With consistency a
great soul has simply nothing to do. -- Ralph Waldo Emerson
