Add support for an HTTP "network filesystem" using the UEFI's HTTP
stack.
This also supports HTTPS, but TianoCore EDK2 implementations currently
crash while fetching loader files.
Only IPv4 is supported at the moment. IPv6 support is planned for a
follow-up changeset.
Note that we include some headers from the TianoCore EDK II project in
stand/efi/include/Protocol verbatim, including links to the license instead
of including the full text because that's their preferred way of
communicating it, despite not being normal FreeBSD project practice.
Submitted by: scottph
Reviewed by: imp, bcran
Differential Revision: https://reviews.freebsd.org/D20643
Don't commit to exclusive access to the network device handle by
efinet until the loader has decided to load something through the
network. This allows for the possibility of other users of the
network device.
Submitted by: scottph
Reviewed by: tsoome, emaste
Tested by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20642
Add the customary warnings to disable format checking on armv7. Code
move to new files, and the unconditional setting of WARNS to 6
provoked it on tinerbox...
This is a primary boot loader that is intended to implement the
gptboot partition selection algorithm just like we did for BIOS
booting. While the preferred method for UEFI is to use the UEFI Boot
Manager protocol, there are situations where that can't be done: some
BIOS makers interfere with the protocol in unhelpful ways, there's a
new standard for a zero variable write from the client OS, and finally
for USB drives that might be mobile between systems with multiple
partitions there needs to be a media stable way to select.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
Segregate the disk probing and selection protocol from the rest of the
boot loader.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
Simplify the code a bit and rework how we report the results
of the probing.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20537
BootServices AllocatePool/FreePool calls. They are simpler to use and
result in the same thing happening.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20540
This is like efi_devpath_match, but allows differing device media
paths. Those just specify the partition information.
Differential Revision: https://reviews.freebsd.org/D20513
looping over the filesystem modules rather than doing a malloc + free
each time through the loop. In addition, nothing changes from loop to
loop, so setup the new devinfo outside the loop as well.
We're storing an EFI_HANDLE, not an pointer to a handle. Since
EFI_HANDLE is a void * anyway, this has little practical effect since
the conversion to / from void * and void ** is silent.
Small mis-merge from multiple WIP resulted in block io media handles getting
double-initialized. This resulted in some installations oddly landing at the
mountroot prompt.
Reported by: ler
Reviewed by: imp
When set, we ignore all the hints that the UEFI boot manager has set
for us. We also always fail back to the OK prompt when we can't find
the right thing to boot rather than failing back to the UEFI boot
manager. This has the side effect of also expanding the cases where we
fail back to the OK prompt to include when we're booted under UEFI,
but UEFI::BootCurrent isn't set in the environment and we can't find a
proper place to boot from.
Reviewed by: bcran
Differential Revision: https://reviews.freebsd.org/D20016
If uefi_rootdev is set in the environment, then treat it like a device
path. Convert the string to a device path and see if we can find a
device that matches. If so, use that device at our root dev no matter
what. If it's bad in any way, the boot will fail.
Reviewed by: bcran
Differential Revision: https://reviews.freebsd.org/D20016
partition as if it were on the command line.
Fetch FreeBSD-LoaderEnv UEFI enviornment variable. If set, read in
loader environment variables from it. Otherwise read in
/efi/freebsd/loader.env. Both are read relative to the device
loader.efi loaded from (they aren't full UEFI device paths)
Next fetch FreeBSD-NextLoaderEnv UEFI environment variable. If
present, read the file it points to in as above and delete the UEFI
environment variable so it only happens once.
This lets one set environment variables in the bootloader.
Unfortunately, we don't have all the mechanisms in place to parse the
file, nor do we have the magic pattern matching in place that
loader.conf has. Variables are of the form foo=bar. No quotes are
supported, so spaces aren't allowed, for example. Also, variables like
foo_load=yes are intercepted when we parse the loader.conf file and
things are done based on that. Since those aren't done here, variables
that cause an action to happen won't work.
Reviewed by: bcran
Differential Revision: https://reviews.freebsd.org/D20016
illumos update: https://www.illumos.org/issues/10598
Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. This will allow to use disk image from file system to load and start the kernel.
By mapping file, we create vdiskX device, the device will be listed by lsdev [-v] and can be accessed directly as ls vdisk0p1:/path or can be used as value for currdev variable.
vdisk strategy function does not use bcache as we have bcache used with backing file. vdisk can be unmapped when all consumers have closed the open files.
In first iteration we do not support the zfs images because zfs pools do keep the device open (there is no "zpool export" mechanism). Adding zfs support is relatively simple, we just need to run zfs disk probe after mapping is done.
Differential Revision: https://reviews.freebsd.org/D19733
snagging them from UEFI BIOS). Call the device type init routines
earlier as well, as they don't depend on how the console is
setup. This will allow us to read files earlier in boot, so any rare
error messages that this might move only to the EFI console will be an
acceptable price to pay. Also tweak the order of has_kbd so it resides
next to the rest of the console code. It needs to be after we initialize
the buffer cache.
When efi_autoload is called it will call fdt_setup_fdtp which setup the
dtb and overlays. If a user already loaded at dtb or overlays or just
printed the efi provided dtb, this will re-setup everything and also
re-applying the overlays.
Test that everything is setup before doing it again.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D20059
Get the information from the image that we're booting and store it in
a global variable. Prefer using this to passing it around. Remove the
special case for zfs that set the preferred boot handle by having it
uses this global variable diretly.
Reviewed by: kevans@
Differential Revision: https://reviews.freebsd.org/D20015
There's no reason we can't setup the console first thing after the
arch flags are setup. We set it undconditionally to efi. This is a
good default, and will get us error messages to at least the efi
console no matter what. This will also prime the pump so that as other
variables are set, they will take effect and the console will be
correct as soon as those env vars are set. Also remove the redundant
setting of the console to efi when we know the console is efi.
Differential Revision: https://reviews.freebsd.org/D20014
There's a number of EFI_ZFS_BOOT #ifdefs that aren't needed, or can be
eliminated with some trivial #defines. Remove the EFI_ZFS_BOOT ifdefs
that aren't needed. Replace libzfs.h include which is not safe to
include without EFI_ZFS_BOOT with efizfs.h which is and now
conditionally included libzfs.h. Define efizfs_set_preferred away
and define efi_zfs_probe to NULL when ZFS is compiled out.
In anticipation of new functionality, create routines to convert char *
and a CHAR16 * to a EFI_DEVICE_PATH
EFI_DEVICE_PATH *efi_name_to_devpath(const char *path);
EFI_DEVICE_PATH *efi_name_to_devpath16(CHAR16 *path);
void efi_devpath_free(EFI_DEVICE_PATH *dp);
The first two return an EFI_DEVICE_PATH for the passed in paths. The
third frees up the storage the first two return when the caller is
done with it.
Differential Revision: https://reviews.freebsd.org/D19971
Add definitions from UEFI 2.7 Errata B standards doc for converting a
text string to a device path. Added clearly missing 'e' at the end of
Device to resolve mismatch in that document in
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL element names.
Differential Revision: https://reviews.freebsd.org/D19971
Newer interfaces take CONST parameters, so define CONST to minimize
differences between our headers and the standards docs.
Differential Revision: https://reviews.freebsd.org/D19971
It was pointed out that manually loading a .dtb to be used rather than
relying on platform-specific method for loading .dtb will result in overlays
not being applied. This was true because overlay loading was hacked into
fdt_platform_load_dtb, rather than done in a way more independent from how
the .dtb is loaded.
Instead, push overlay loading (for now) out into an
fdt_platform_load_overlays. This method easily allows ubldr to pull in any
fdt_overlays specified in the ub env, and omits overlay-checking on
platforms where they're not tested and/or not desired (e.g. powerpc). If we
eventually stop caring about fdt_overlays from ubenv (if we ever cared),
this method should get chopped out in favor of just calling
fdt_load_dtb_overlays() directly.
Reported by: Manuel Stühn (freebsdnewbie freenet de)
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
UEFI related headers were copied from edk2.
A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
loading of trusted anchors from UEFI.
Certificate revocation support is also introduced.
The forbidden certificates are loaded from dbx variable.
Verification fails in two cases:
There is a direct match between cert in dbx and the one in the chain.
The CA used to sign the chain is found in dbx.
One can also insert a hash of TBS section of a certificate into dbx.
In this case verifications fails only if a direct match with a
certificate in chain is found.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19093
The call to BS->AllocatePages can cause the memory map to become framented,
causing BS->GetMemoryMap to return EFI_BUFFER_TOO_SMALL more than once. For
example this can happen on the MinnowBoard Turbot, causing the boot to stop
with an error. Avoid this by calling GetMemoryMap in a loop.
Reviewed by: imp, tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D19341
ExitBootServices terminates all boot services including console access.
Attempting to call printf afterwards can result in a crash, depending on the
implementation.
Move any printf statements to before we call bi_load, and remove any that
depend on calling bi_load first.
Reviewed by: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D19374
r328169 removed the copy of bootinfo that would've made this somewhat
functional. However, this is irrelevant- earlier work in r292338 was done to
exit boot services in the MI bi_load() rather than having N copies of the
GetMemoryMap/ExitBootServices dance.
i386 never quite caught up to that; ldr_enter was still being called but
the prereq for that, ldr_bootinfo, was no longer. As a consequence, this
ExitBootServices() was being called with a mapkey=0, clearly bogus, and
reportedly breaking the boot in some instances.
Reported by: bcran
MFC after: 1 week
When loading bigger variables form UEFI it is necessary to know their
size beforehand, so that an appropriate amount of memory can be
allocated. The easiest way to do this is to try to read the variable
with buffer size equal 0, expecting EFI_BUFFER_TOO_SMALL error to be
returned. Allow such possible approach in efi_getenv routine.
Extracted from a bigger patch as suggested by imp.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.
Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
This update does add diag and debug capabilities to interpret the efi
variables, configuration and protocols (lsefi).
The side effect is that we add/update bunch of related headers.
With the default Qemu parameters, only 128MB RAM gets given to a VM. This causes
the loader to be unable to allocate the 64MB it needs for the heap. This change
makes the cause of the error more obvious.
Differential Revision: https://reviews.freebsd.org/D17958
This fix is ported from illumos (issue #9970), the analysis and initial
implementation was done by John Levon.
See also: https://www.illumos.org/issues/9970
Currently, efi_cons_getchar() will wait for a key. While this seems to make
sense, the implementation of getchar() in common/console.c will loop across
getchar() for all consoles without doing ischar() first.
This means that if we've configured multiple consoles, we can't input into
the serial, as getchar() will be sat waiting for input only from efi_console.c
This patch does implement a bit more generic key buffer to support
translation of input keys, and we use generic efi_readkey() to reduce
duplication from calls from getchar() and poll().
Pointer math to find the size in bytes only works with char types.
Use correct pointer math to determine if we have enough of a header to
look at or not.
MFC After: 3 days
X-MFX-With: r339800
Noticed by: jhb@
Sponsored by: Netflix, Inc
its length. Some BIOSes pad the length of the device path to an even
amount. When we had a device path that was somehow an odd length, we'd
wind up having 1 byte left that we were bogusly interpreting as a full
device path. We'd then dereference 2 bytes into that to get a length
of the node, which had undefined (and quite undesired) effects.
Sponsored by: Netflix, Inc
MFC After: 3 days
Add poweroff command to make life a bit easier.
Reviewed by: imp, allanjude
Approved by: re (kib)
Differential Revision: https://reviews.freebsd.org/D17535
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
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
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
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
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]
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.
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.
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.
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
