file_loadraw():
check for file_alloc() and strdup() results.
we leak 'name'.
mod_load() does leak 'filename'.
mod_loadkld() does not need to check fp, file_discard() does check.
Since the partition/slice names do vary in length, check the length
of the fixed part of the line against 3 * 8, if the lenth is less than
3 tab stops, print out extra tab.
use snprintf() instead of sprintf.
This is a prerequisite of unifying kernel zlib instances.
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20191
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.
The bug and patch is reported against 11.2, but it is good idea to have
the check in place for all versions.
PR: 236585
Submitted by: john@feith.com
Reported by: john@feith.com
MFC after: 1 day
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
These three cases dovetail with other places in the code where we use
or set D_PARTISGPT when we mean that the partitioning scheme is
GPT. Use this #define to make the code easier to undertand.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20122
If we do have GPT on disk, read the disk size from it and do not
call int13.
Since int13 does report bogus informatiopn too often, rather trust the
partition table. We are using the same strategy with loader.
MFC after: 1 month
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
The disk_open() function searches for "the best partition" when slice and
partition information is not provided as part of the device name. As of
r345477 the slice and partition fields of a disk_devdesc are initialized to
D_SLICEWILD and D_PARTWILD; in the past they were initialized to -1, which
was sometimes interpreted as meaning 'wildcard' and sometimes as 'open the
raw partition' depending on the context. So as an unintended side effect of
r345477 it became basically impossible to ever open a disk or partition
without doing the 'best partition' search. One visible effect of that was
the inability to open the raw disk to read the partition table correctly in
zfs_probe_dev(), leading to failures to find the zfs pool unless it was on
the first partition.
Now instead of always initializing slice and partition to wildcards, the
disk_parsedev() function initializes them based on the presence of a
path/file name following the device. If there is any path or filename
following the ':' that ends the device name, then slice and partition are
initialized to D_SLICEWILD and D_PARTWILD. If there is nothing after the
':' then it is considered to be a request to open the raw device or
partition itself (not a file stored within it), and the fields are
initialized to D_SLICENONE and D_PARTNONE.
With this change in place, all the tests in src/tools/boot are succesful
again, including the recently-added cases of booting from a zfs pool on
a partition other than slice 1 of the device.
PR: 236981
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)
346002 did miss the fact that we do not only undo the loadaddr, but also
we need to remove the inserted module. Implement file_remove() to do the job.
MFC after: 1w
The last_file variable is used to reset the loadaddr variable back to original
value; however, it is possible the last_file is NULL, so we can not blindly
trust it. But then again, we can just save the original loadaddr and use
the saved value for recovery.
MFC after: 1w
The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
entries into kernel using a char device (/dev/veriexec).
This requires verifying root partition integrity in loader,
for example by using memory disk and checking its hash.
Otherwise if rootfs is compromised an attacker could inject their own data.
This patch introduces an option to parse manifest in kernel based on envs.
The loader sets manifest path and digest.
EVENTHANDLER is used to launch the module right after the rootfs is mounted.
It has to be done this way, since one might want to verify integrity of the init file.
This means that manifest is required to be present on the root partition.
Note that the envs have to be set right before boot to make sure that no one can spoof them.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19281
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS.
Note that in some cases there are small differences in the generated
output, so CLANG_NO_IAS should be removed only after testing (or after
finding no differences in the output). For zfsldr I compared objdump
output between GNU as- and Clang IAS-built zfsldr and .text was
identical (changes were limited to the object's ELF headers and debug
info).
Sponsored by: The FreeBSD Foundation
Assuming that the autoboot sequence was interrupted, we've done enough
cursor manipulation that the prompt for the password will be sufficiently
obscured a couple of lines up. Clear the screen and reset the cursor
position here, too.
MFC after: 1 week
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
The loader indended to search the kernel file name (only) for . but
instead searched the entire path, so paths like
"boot/test.elfv2/kernel" would not work.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: kevans
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19658
During initialization of the forth interpreter
the loader looks for "/boot/boot.4th"
and executes any code found there.
That file was loaded bypassing verification.
Add a call to verify_file to change that.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
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
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
This relies on libbearssl and libsecureboot
to verify files read by loader in a maner equivalent
to how mac_veriexec
Note: disabled by default.
Use is initially expected to be by embeded vendors
Reviewed by: emaste, imp
Sponsored by: Juniper Networks
Differential Revision: D16336
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
The cd9660_open() does pass whole path to dirmatch() and we need to
compare only the current path component, not full path.
Additinally, skip over duplicate / (if any) and check if the last component
in the path was meant to be directory (having trailing /). If it is in fact
a file, error out.
When I added support for the standard loader(8) disk0s2a: type formats,
the parsing of legacy format was broken because it also contains a colon,
but it comes before the slice and partition. That would cause disk_parsedev()
to return success with the slice and partition set to wildcard values.
This change examines the string first, and if it contains spaces, dots, or
a colon at any position other than the end, it must be a legacy-format
string and we don't even try to use disk_parsedev() on it.
Reported by: Manuel Stuhn
way: device<unit>[s|p]<slice><partition>. E.g., disk0s2a or disk3p12.
The code first tries to parse the variable in this format using the
standard disk_parsedev(). If that fails, it falls back to parsing the
legacy format that has been supported by ubldr for years.
In addition to 'disk', all the valid uboot device names can also be used:
mmc, sata, usb, ide, scsi. The 'disk' device serves as an alias for all
those types and will match the Nth storage-type device found (where N is
the unit number).
Loader does fail to properly match the file name in directory record and
does open file based on prefix match.
For fix, we check the name lengths first.
Reviewed by: allanjude
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19213
loaderdev variable works correctly.
The uboot_devdesc struct is variously cast back and forth between
uboot_devdesc and disk_devdesc as pointers are handed off through various
opaque interfaces. uboot_devdesc attempted to mimic the layout of
disk_devdesc by having a devdesc struct, followed by a union of some
device-specific stuff that included a struct that contains the same fields
as a disk_devdesc. However, one of those fields inside the struct is 64-bit
which causes the entire union to be 64-bit aligned -- 32 bits of padding
is added between the struct devdesc and the union, so the whole mess ends
up NOT properly mimicking a disk_devdesc after all. (In disk_devdesc there
is also 32 bits of padding, but it shows up immediately before the d_offset
field, rather than before the whole collection of d_* fields.)
This fixes the problem by using an anonymous union to overlay the devdesc
field uboot network devices need with the disk_devdesc that uboot storage
devices need. This is a different solution than the one contributed with
the PR (so if anything goes wrong, the blame goes to me), but 95% of the
credit for this fix goes to Pawel Worach and Manuel Stuhn who analyzed the
problem and proposed a fix.
PR: 233097
This was previously an unconditional screen clear, regardless of whether or
not we would be prompting for any passwords. This is pointless, given that
the screen clear is only there to put our screen into a consistent state
before we draw the prompts and do cursor manipulation.
This is also the only screen clear besides that to draw the menu. One can
now see early pre-loader and loader output with the menu disabled, which may
be useful for diagnostics.
Reported by: ian
MFC after: 3 days
Summary:
Now that mpc85xx can boot via ubldr, move ubldr to a separate
filesystem, mounted on /boot/uboot, so that a fresh install can boot correctly.
Reviewed By: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D18709
the size field and a tab between the partition type and the size.
Changes this
disk devices:
disk0 (MMC)
disk0s1: DOS/Windows 49MB
disk0s2: FreeBSD 14GB
disk0s2a: FreeBSD UFS 14GB
disk0s2b: Unknown 2048KB
disk0s2d: FreeBSD UFS 2040KB
to this
disk devices:
disk0 (MMC)
disk0s1: DOS/Windows 49MB
disk0s2: FreeBSD 14GB
disk0s2a: FreeBSD UFS 14GB
disk0s2b: Unknown 2048KB
disk0s2d: FreeBSD UFS 2040KB
I'm pretty sure this used to work at one time, perhaps long ago. It has
been failing recently because if you call disk_open() with dev->d_partition
set to -1 when d_slice refers to a bsd slice, it assumes you want it to
open the first partition within that slice. When you then pass that open
dev instance to ptable_open(), it tries to read the start of the 'a'
partition and decides there is no recognizable partition type there.
This restores the old functionality by resetting d_offset to the start
of the raw slice after disk_open() returns. For good measure, d_partition
is also set back to -1, although that doesn't currently affect anything.
I would have preferred to make disk_open() avoid such rude assumptions and
if you ask for partition -1 you get the raw slice. But the commit history
shows that someone already did that once (r239058), and had to revert it
(r239232), so I didn't even try to go down that road.
This commit fixes a remaining output buffer overrun in the
single-sector case when there is a non-zero tail.
Reviewed by: allanjude, tsoome
MFC after: 3 months
MFC with: r344226
Differential Revision: https://reviews.freebsd.org/D19220
This is consistent with the removal of whole-disk vdev support from
libsa/zfs/zfs.c in r342151, and is part way to having the LBAs read
during probe be fully constrained by partition tables when present.
Reviewed by: tsoome
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D19142
The bug occurred when a bounce buffer was used and the requested read
size was greater than the size of the bounce buffer. This commit also
rewrites the read logic so that it is easier to systematically verify
all alignment and size cases.
Reviewed by: allanjude, tsoome
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D19140
Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).
With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.
MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.
Currently only dynamically linked binaries will be built as PIE.
Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423
net_open previously casted the first vararg to a char * and this was
half-OK: at first, it is passed to netif_open, which would cast it back to
the struct devdesc * that it really is and use it properly. It is then
strdup()d and used as the netdev_name, which is objectively wrong.
Correct it so that the first vararg is properly casted to a struct devdesc *
and the netdev_name gets set properly to make it more clear at a glance that
it's not doing something horribly wrong.
Reported by: mmel
Reviewed by: imp, mmel, tsoome
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19206
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)
Since the loader zfs reader does not need to read the dump zvol, we can
just enable the feature.
illumos issue #9051https://www.illumos.org/issues/9051
MFC after: 2 weeks
An integrity check such as a check-hash or a cross-correlation failed.
The integrity error falls between EINVAL that identifies errors in
parameters to a system call and EIO that identifies errors with the
underlying storage media. EINTEGRITY is typically raised by intermediate
kernel layers such as a filesystem or an in-kernel GEOM subsystem when
they detect inconsistencies. Uses include allowing the mount(8) command
to return a different exit value to automate the running of fsck(8)
during a system boot.
These changes make no use of the new error, they just add it. Later
commits will be made for the use of the new error number and it will
be added to additional manual pages as appropriate.
Reviewed by: gnn, dim, brueffer, imp
Discussed with: kib, cem, emaste, ed, jilles
Differential Revision: https://reviews.freebsd.org/D18765
Just like for Acer C270 chromebook the E820 extmem workaround is required for
FreeBSD to boot on Dell chromebook.
PR: 204916
Submitted by: Keith White <kwhite@site.uottawa.ca>
MFC after: 1 week
biospci_write_config args swapped length and value to write. Some
hardware coped just fine, while other hardware had issues.
PR: 155441
Submitted by: longwitz at incore dot de
We have no option than trust INT13 ah=08 return code during the init phase.
PR: 234460
Reported by: Oleh Hushchenkov
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18723
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.
We do have 16KB buffer space defined in pxe.c, move it to bio.c and implement
bio_alloc()/bio_free() interface to make it possible to use this space for
other BIOS calls (notably, from biosdisk.c).
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D17131
The reason for this change is that currently, a send/recv
takes many hours to time out.
This is suboptimal in the bootloader because it means for example
that NFS will take hours to fail before allowing subsequent access
methods such as gzip to be tried.
Setting MAXWAIT to 300 seconds (5 minutes) still allows slow
connections of 1Mb to be used to download a 30MB kernel file.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18544
