If cnt == 0 we access element 0 unconditionally, which is out of bounds,
and then if that doesn't crash and happens to be 0 we will access
element - 1, also out of bounds, and then if that doesn't crash will add
1 to whatever junk is there and use that for the variable. On CHERI,
though, this does crash. This code is also overly complicated, with
unnecessary special cases and tracking more state than needed.
Rewrite it in a more general manner that doesn't need those special
cases and naturally works for cnt == 0.
Found by: CHERI
Reviewed by: imp
Fixes: 1285bcc833 ("Import Netflix's efibootmgr to help manage UEFI boot variables")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44029
I observed the problem on a system with fairly old and, apparently,
buggy EFI implementation. A list of boot devices had an invalid
trailing entry. efidp_size() for that entry returned zero, which means
that the code got stuck looping on that entry.
Report the entire path to the device, rather than the the bit after /dev/
for the --esp command. Nothing in the tree depends on the output
format: Only bsdinstall's bootconfig script calls efibootmgr, and it
doesn't use the --esp/-E flag.
Sponsored by: Netflix
-C isn't implemented, so just errx out until it is. It's not listed in
the man page, but is parsed for compatibility with the Linux
efibootmgr(8) command.
Sponsored by: Netflix
This should be less confusing for new users.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42213
The removal of the sparc64 support in February 2020 obsoleted the
VTOC8 partitioning scheme as no other FreeBSD platform makes use
of it. Moreover, the code is bitrotting as nothing defines e. g.
LOADER_VTOC8_SUPPORT any more and, thus, should go now, too. With
this change, the following commits are reverted as far as VTOC8
is concerned and parts haven't already previously been deleted
along with prior sparc64 removals:
094fcb157da7d366e958ba8d50d08b
The alignment example d9711c28ef
added to the VTOC8 section of gpart.8 is folded into the MBR one.
This should finally conclude the deorbit of sparc64-specific bits.
We had joy, we had fun
we ran Unix on a Sun.
But that source and the song
of FreeBSD have all gone.
Credits to Michael Bueker for the original "Unix on a Sun" and Rod
McKuen for the "Seasons in the Sun" lyrics.
"efibootmgr --efidev unix-path" will return the UEFI device-path to the
file or device specified by unix-path. It's useful for debugging, but
may also be useful for scripting.
Sponsored by: Netflix
Reviewed by: corvink, manu
Differential Revision: https://reviews.freebsd.org/D38617
Move the check for efi variables being supported to after parsing the args. This
allows '-h' to produce both as a normal user as well as on all systems.
efivar_device_path_to_unix_path() returns standard error codes on
failure and zero on success. Checking for a return value less than zero
means that the actual failure cases won't be handled. This could
manifest as a segfault during the subsequent call to printf().
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D27424
efivar_unix_path_to_device_path returns the error code, it does not set errno.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26852
The OsIndications UEFI variable can request the firware to stop at
its UI instead of continuing with boot. Add flags for setting and
clearing this request.
Reviewed by: manu, bcr (manpages)
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D25839
Add code to decode the BootCurrent and BootXXXX variable it points at
to deduce the ESP used to boot the system. By default, it prints the
path to that device. With --unix-path (-p) it will instead print the
current mount point for the ESP, if any (or an error). With
--device-path (-d) it wil print the UEFI device path for the ESP.
Note: This is the best guess based on the UEFI variables. If the ESP
is part of a gmirror, etc, that won't be reported. If by some weird
chance there was a complicated series of chain boots, this may not be
what you want. For setups that don't add layers on top of the raw
devices, it is accurate.
Differential Revision: https://reviews.freebsd.org/D22432
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)
Instead of passing the bootnum to each different parameter, require users
to specify -b when running operations that need a bootnum.
This allows activation of a new boot entry at the same time it's created
by adding -a onto the command line.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18648
than the auotmatic selection). This is important in some scripting
environments.
Also, remove bogus checks for bootnum != 0. 0 is a valid bootnum.
Sponsored by: Netflix
The --device and --part command line options were planned for Linux
compatibility mode. However, that mode will never happen, so remove
them as last vestiges of a false start.
Submitted by: Vlad Movchan
Print the boot variables in the order in the BootOrder variable, if it
exists, and then in verbose mode print any unreferneced BootXXXX
variables. If BootOrder isn't set, fall back to printing all the
variables.
Sponsored by: Netflix
This squashes the warning gebnerated by GCC 6.x. Since
variables that are now removed had come documentation
value, put relevant bits in comment, so they can be
resurrected from there when actually needed.
efibootmgr manages the UEFI BootXXXX variables that implement the UEFI
Boot Manager protocol defined in the UEFI standards. It is modeled
after the Linux program of the same name with a mostly compatible set
of command line options. Since there's a fair amount of OS specifioc
code due to differeing names and methods of doing things, the
compatibility isn't 100%.
Basic functionality is implemented, though the more advanced next boot
functionality that's been defined elsewhere is unimplemented.
Submitted by: Matt Williams (with unix / efi path xlate by me)
Sponsored by: Netflix
