They're never going to be installed, and moving them here makes adding a
test-suite (and porting to meson) easier.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Since UEFI 2.2, firmware has provided a list of supported signature
types for Secure Boot binaries in a global variable named
"SignatureSupport".
This patch adds a new command line flag to efibootmgr,
"--list-signature-types" ("-s") which collects that information from the
firmware and displays it to the user, either by symbolic name if
libefivar knows about that signature type or by GUID if it does not.
On the system in front of me, that looks something like this:
random:efibootmgr/signaturesupport$ ./src/efibootmgr -s
x509_sha256
x509_sha384
x509_sha512
sha256
x509_cert
rsa2048
rsa2048_sha256
rsa2048_sha1
external_management
random:efibootmgr/signaturesupport$ ./src/efibootmgr -s -v
x509_sha256 3bd2a492-96c0-4079-b420-fcf98ef103ed
x509_sha384 7076876e-80c2-4ee6-aad2-28b349a6865b
x509_sha512 446dbf63-2502-4cda-bcfa-2465d2b0fe9d
sha256 c1c41626-504c-4092-aca9-41f936934328
x509_cert a5c059a1-94e4-4aa7-87b5-ab155c2bf072
rsa2048 3c5766e8-269c-4e34-aa14-ed776e85b3b6
rsa2048_sha256 e2b36190-879b-4a3d-ad8d-f2e7bba32784
rsa2048_sha1 67f8444f-8743-48f1-a328-1eaab8736080
external_management 452e8ced-dfff-4b8c-ae01-5118862e682c
random:efibootmgr/signaturesupport$
Signed-off-by: Peter Jones <pjones@redhat.com>
This reverts commit 5ce076c88670eeb63dea80fcaec60e79f0e57ac6.
This was pulled in prematurely; the support code isn't merged in efivar yet.
Signed-off-by: Peter Jones <pjones@redhat.com>
When deleting bootnext, there's nothing to validate (other than
the variable existing, in which case del will fail as expected).
This appears to be a copy/paste error when adding the delete-bootnext
option from the [create] bootnext option.
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
According to https://github.com/rhboot/efibootmgr/issues/101, the
--write-signature option does nothing. This change removes the option.
Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
New --uri option enables to specify a URI when creating a network boot
entry, e.g.
# efibootmgr -L NetBoot -i enp7s0 --uri http://foobar/grubx64.efi
This requires support in libefiboot, which is provided by version 39 of
efivar.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
Size of the order entry size (uint16_t) hasn't been taken into account for all calculations and caused memory corruption.
Signed-off-by: kamillo <kamilgolunski@gmail.com>
- Add missing -f/-F option in README.
- Start first letter of help message with a capital letter and
end with a period punctuation to make things consistent with
other option messages.
- Use two spaces after period punctuation before new sentence.
- Correct some spelling mistakes.
Signed-off-by: Robert Scheck <robert@fedoraproject.org>
Drop the code to test development heads against each other since it has
atrophied (last updated when rawhide was fc32).
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Check that the current character is not the null character after
ensuring we are not beyond the end of the buffer.
Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Fixes several issues, including --enable-dups and -k not being
recognized, as well as -g requiring an unused argument.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Currently there is no way to delete entries specified by a label. This
patch adds that ability, such that "efibootmgr -B -L Debian" will delete
any entry with the label 'Debian'.
The existing error message looks to be a copy and paste
from the set_order handler. Replace the error message
with something related to the specified command.
Signed-off-by: Ryan Harper <ryan.harper@canonical.com>
Previously we decided if a character was printable on a byte-by-byte
basis, and if the character was not printable, showed "." like "hexdump -C"
does. hexdump gets away with this because the hex is there, but we
don't have that going on.
This patch changes it to decide up front if there are *any* unprintable
characters, and if so, dump hex for the whole thing instead of printing
useless nonsense.
(Incidentally this also alphabetizes the include files, because I like
that better.)
Fixes github issue #123
Signed-off-by: Peter Jones <pjones@redhat.com>
We've currently got "-e N" and "-E num" arguments that effectively just
force a full device path or an abbreviated device path, but may
sometimes detect some shell mapping that got left around. This leaves
some people thinking they're actually doing something with EDD, which
they really aren't.
This patch does a couple of things:
- adds --full-dev-path, which forces a full (ACPI/PCIe/etc-rooted)
device path to be generated.
- adds --file-dev-path, which forces a File() based device path to be
generated.
- Adds an alias for --edd30 to --edd
- makes "-e 3" / "--edd 3" do the same thing as --full-dev-path.
- removes "-e -1", which makes no sense anyway
- gets rid of the EFI shell device map parsing, which probably worked
anyway, since the old edk shell code here
https://github.com/tianocore/edk-Shell/blob/master/shellenv/map.c#L1019
only ever generates the binaries with EFI_VARIABLE_BOOTSERVICE_ACCESS,
so that could never have worked. The code in edk2's shell package
doesn't expose these as variables.
- updates docs to say what it's actually doing.
Signed-off-by: Peter Jones <pjones@redhat.com>
The intent is that force is not default, so all the tests for it need to
be testing for >0 rather than !0.
Fixes github issue #119
Signed-off-by: Peter Jones <pjones@redhat.com>
This tries to do a better job printing optional data blobs:
- if it detects a device path that ends in shim, it assumes it's a file
path:
before:
Boot0000* Linux Firmware Updater HD(1,GPT,58da233f-b177-4c57-8bee-3d888b3047d4,0x800,0x64000)/File(\EFI\fedora\shimx64.efi)\.f.w.u.p.d.x.6.4...e.f.i...
after:
Boot0000* Linux Firmware Updater HD(1,GPT,58da233f-b177-4c57-8bee-3d888b3047d4,0x800,0x64000)/File(\EFI\fedora\shimx64.efi) File(.\fwupdx64.efi)
- if the loader is 16-bytes, it formats it as an id guid
before:
Boot0004* UEFI ATAPI iHAS324 E 3524706 2B8427502710 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)N.....YM....R,Y.
after:
Boot0004* UEFI ATAPI iHAS324 E 3524706 2B8427502710 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0){8108ac4e-9f11-4d59-850e-e21a522c59b2}
or if it recognizes the guid (which in this case depends on a newer libefivar):
Boot0004* UEFI ATAPI iHAS324 E 3524706 2B8427502710 PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0){auto_created_boot_option}
where the value between {} is the value from "efivar -L":
trillian:~/devel/github.com/efivar/master$ LD_LIBRARY_PATH=$PWD/src/ ./src/efivar -L | grep auto_created_boot_option
{8108ac4e-9f11-4d59-850e-e21a522c59b2} {auto_created_boot_option} efi_guid_auto_created_boot_option Automatically Created Boot Entry
Signed-off-by: Peter Jones <pjones@redhat.com>
When we're doing make deps with "$(CC) -MF", gcc and clang have different
behavior, both broken in different ways, which we're hitting because of a
missing -I argument for libefivar's includes. On clang, when a header can't
be found, it emits a rule with the header as a prerequisite without a path,
such as efivar.h here:
efibootmgr.o: efibootmgr.c fix_coverity.h efivar.h efiboot.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \
error.h
Then the build that utilizes that rule will fail to find the
prerequisite and tell you something like:
make[1]: *** No rule to make target 'efivar.h', needed by 'efibootmgr.o'. Stop.
make[1]: Leaving directory '/home/pjones/devel/github.com/efibootmgr/master/src'
With gcc, when a header can't be found, it emits a rule without that header
as a prerequisite, as such (again with efivar.h):
efibootmgr.o: efibootmgr.c fix_coverity.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \
error.h
And then your build will fail if you haven't adjusted CFLAGS to tell it
where to find the header.
Both of these would be better just erroring, but at least gcc's doesn't
insert a *wrong* dependency.
This patch adds "PKGS=efivar efibootmgr popt" for all deps under src/.
Technically that's overkill, as efibootmgr itself doesn't need popt, but it
doesn't hurt anything to have the extra part there. The resulting
.efibootmgr.d file has the prerequisites expressed correctly:
efibootmgr.o: efibootmgr.c fix_coverity.h /usr/include/efivar/efivar.h \
/usr/include/efivar/efiboot.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/list.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/unparse_path.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efi.h \
/home/pjones/devel/github.com/efibootmgr/master/src/include/efibootmgr.h \
error.h
This fixes the issue described in github PR #96
Signed-off-by: Peter Jones <pjones@redhat.com>
