| Age | Commit message (Collapse) | Author |
|---|
|
In issues #554 and elsewhere, it's been noted that when fallback is
creating multiple entries, it will create them in one order and add them
to BootOrder in the opposite order. This is weird.
This patch changes fallback to keep a list of "new" entries, and then
prepend that entire list to BootOrder when it's done, rather than
prepending one at a time, that avoiding the inversion.
Resolves issue #554.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Move some functions currently used within fallback that will later also
be used in shim.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
In case CSV entry contains boot argument (e.g. an image to load for shim)
it must be null-terminated. While populate_stanza() makes sure 'arguments'
end with '\0', add_boot_option() doesn't account for it in 'size'
calculations. E.g. for the following CSV entry:
shimx64.efi,6.6.0-0.rc0.20230904git708283abf896.6.fc40.x86_64,\EFI\Linux\5f93b3c9cf1c488a99786fb8e99fb840-6.6.0-0.rc0.20230904git708283abf896.6.fc40.x86_64.efi,Comment
the resulting variable after 'fallback' looks like:
# hexdump /sys/firmware/efi/efivars/Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c | tail -3
0000180 0038 0036 005f 0036 0034 002e 0065 0066
0000190 0069
0000192
Add trailing '\0' to 'size' calculations in add_boot_option() when
'arguments' is not empty. The resulting variable looks like:
# hexdump /sys/firmware/efi/efivars/Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c | tail -3
0000180 0038 0036 005f 0036 0034 002e 0065 0066
0000190 0069 0000
0000194
and the specified image is loaded by shim without issues.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
|
|
The variable fallback_verbose_wait from now on is of the type unsigned
long to match the type of the argument usleep() accepts.
Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
|
|
The function msleep uses gBS->Stall which waits for a specified number
of microseconds.
Reference: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/5_uefi_services/51_services_that_uefi_drivers_commonly_use/517_stall
This reference even mentions an example sleeping for 10 microseconds: // Wait 10 uS. Notice the letter 'u'.
Therefore it's a good idea to call the function 'usleep' rather than
'msleep', so no one confuses it with milliseconds, and to change the
argument name to match as well.
Signed-off-by: Kamil Aronowski <kamil.aronowski@yahoo.com>
|
|
This makes SHIM_VERBOSE / SHIM_DEVEL_VERBOSE work the same way as
SHIM_DEBUG / SHIM_DEVEL_DEBUG when shim is built with ENABLE_SHIM_DEVEL
set.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
- one missing free
- one minor deadcode issue
- two unchecked allocations
- one debug hexdump of a variable we just freed
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The buffer used to read the data in the CSV is declared as a stack variable
in the try_boot_csv() function, but a pointer to the arguments field of the
first boot option is stored in the global first_new_option_args variable.
Later, when is used set the arguments to boot the first entry, the variable
points to memory that no longer exists. This leads to booting an entry with
garbage as arguments instead of the correct value.
Reported-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
Seen on Dell PowerEdge R740 when booting with BOOTX64 constantly.
This patch keeps the behaviour previous to commit #1b30c2b by returning
the index of the "Linux" entry.
Then a check is made to find the entry in the current BootOrder:
- if it isn't there, prepend the entry and copy the rest (this enlarges
the BootOrder array by 1)
- if it's there, prepend the entry and copy all remaining entries
------------------------------------------------------------------------------
Example of outputs on a Dell PowerEdge R740:
- 0000 is BOOTX64 entry
- other entries are Dell's default ones (internal, no "Linux" there)
1. Entry not already existing in BootOrder
----
set_boot_order:486: Original nbootorder: 3
Original BootOrder: 0000 0003 0004
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
find_boot_option:454: Found boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_to_boot_list:623: New nbootorder: 4
BootOrder: 0005 0000 0003 0004
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0003 0004
----
2. Entry not existing at all
----
set_boot_order:486: Original nbootorder: 3
Original BootOrder: 0000 0001 0002
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
add_boot_option:245: Creating boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_boot_option:282: nbootorder: 4
BootOrder: 0005 0000 0001 0002
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0001 0002
----
3. Entry already existing in BootOrder
----
set_boot_order:486: Original nbootorder: 4
Original BootOrder: 0000 0005 0001 0002
:
add_to_boot_list:578: device path: "HD(1,GPT,99D47E76-590F-48FD-8FD6-0A0CE790D635)/\EFI\redhat\shimx64.efi"
find_boot_option:454: Found boot entry "Boot0005" with label "Red Hat Enterprise Linux" for file "\EFI\redhat\shimx64.efi"
add_to_boot_list:623: New nbootorder: 4
BootOrder: 0005 0000 0001 0002
find_boot_options:937: Found directory named "Dell"
update_boot_order:509: nbootorder: 4
BootOrder: 0005 0000 0001 0002
----
|
|
entry in optnum"
This reverts commit 1b30c2b9e5ee7d3e305a28a92805152d5cbfc9cb.
This commit was creating duplicated entries when the "Linux" entry was
not already in the BootOrder list, which may happen upon firmware reset.
|
|
This just makes one less thing we have to make sure is the same between
the test harnesses and the runtime code.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In the cloud, all boots are non-interactive with keyboard and console
access either typically not available or prohibited. Also clouds
always do firstboot via fallback. This currently results in an
unacceptable 5s boot delay whilst fallback offers interactive reset
options that cannot be actioned.
In Ubuntu, we'd like to make fallback noninteractive by default
without any boot delays, due to bootspeed impact on firstboot of the
preinstalled images.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1922581
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
|
|
Now that we are iterating over all EFI variables to look for duplicate
boot entries, we should use a dynamic buffer, so if the firmware tells
us the buffer is too small for the next variable name we can re-allocate
it to a big enough size.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
When listing all variables checking for duplicates, print which error
was returned if not EFI_NOT_FOUND (which simply means reached the end of
the list).
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Heinrich correctly noticed that read_file()'s memory allocation failure
error path tested the wrong variable, and thus would never catch the
error condition. The *next* error, file->Read() failing, has the same
incorrect variable usage in its FreePool() invocation.
This fixes it to free the right variable as well.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
After calling AllocateZeroPool() we must check the returned pointer.
Fixes: 3ce517fdbb4e ("Add a fallback loader for when shim is invoked as BOOTX64.EFI")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
optnum
The CopyMem() calls in add_to_boot_list() expect that
find_boot_option() returned an index to the matching entry in the
BootOrder array. The previous code returned the numerical portion of
the boot entry label, which in some cases resulted in -1 *
sizeof(CHAR16) being passed to CopyMem() which would in turn corrupt
the running firmware resulting in an exception and a failure to boot
or reset.
|
|
If FALLBACK_VERBOSE is defined at build time the resulting fallback will
always be verbose despite having the EFI variable defined or not, which
facilitates testing in some scenarios.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Make it possible to configure at build time for how long fallback will
wait before moving to the next step when in verbose mode.
Also remind the user they can press the Pause key to pause the boot
process at that point.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Currently we wait half a second before resetting the system when running
fallback in verbose mode. Lets wait the same amount of time before
trying to chain-load the first boot entry as well, so we have a chance
to see what is on screen.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
This helps to identify when the firmware messes up the boot entries
created by fallback.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Only print what fallback is doing when running in verbose mode. This way
we can have a silent boot even when fallback is doing its thing.
This commit is based on a previous patch by Carlo Caione.
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
This removes the last use of '#ifdef DEBUG_FALLBACK".
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Some firmware implementations like the one on the Acer TravelMate
P449-G2-MG completely ignore the value of BootOrder set by fallback, and
overwrite it with a value of its own. On this particular machine, the
boot entry created by fallback on the previous boot is not included by
the firmware on this new BootOrder, so it is not considered when
checking for duplicates.
This problem is agravated by the fact that such firmware does not give
the user the possibility to manually boot from any entry created outside
of the firmware setup program -- the only way to boot a distro that
deploys "the fallback ESP layout" and no \EFI\BOOT\grubx64.efi with this
firmware is through \EFI\BOOT\BOOTX64.EFI. The side effect here is
having a new boot entry created by fallback on every boot.
This commit makes fallback try every Boot* variable when checking for
duplicates, not only the ones listed in BootOrder, so it can find the
duplicate Boot entry and re-use it instead of creating a new one.
https://phabricator.endlessm.com/T15481
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessos.org>
|
|
This re-structures our includes so we can be sure everything is always
including all the system headers in a uniform, predictable way.
Temporarily it also adds a bunch of junk at all the places we use
variadic functions to specifically pick either the MS (cdecl) or ELF
ABIs.
I'm not 100% sure that's all correct (see later patch) but it's enough
to allow this to build.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Some machines with the faulty firmware may keep booting the default boot
path instead of the boot option we create. To avoid the infinite reset
loop, this commit introduce a countdown screen before fallback resets the
system, so the user can interrupt the system reset and choose to boot
the restored boot option. The "Always continue boot" option creates a
BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot
option afterward without asking. The user can revert the behavior by
removing the variable.
https://github.com/rhboot/shim/issues/128
Signed-off-by: Gary Lin <glin@suse.com>
This is a backport from devel of:
commit da6284569c4b5d60d14e6187f696f54cccb7b3d2
Author: Gary Lin <glin@suse.com>
Date: Wed May 23 18:13:05 2018 +0800
fallback: show a countdown menu before reset
Some machines with the faulty firmware may keep booting the default boot
path instead of the boot option we create. To avoid the infinite reset
loop, this commit introduce a countdown screen before fallback resets the
system, so the user can interrupt the system reset and choose to boot
the restored boot option. The "Always continue boot" option creates a
BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot
option afterward without asking. The user can revert the behavior by
removing the variable.
https://github.com/rhboot/shim/issues/128
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The license statements in our source files were getting to be a giant
mess, and mostly they all just say the same thing. I've switched most
of it to SPDX labels, but left copyright statements in place (where they
were not obviously incorrect copy-paste jobs that I did...).
If there's some change here you don't think is valid, let me know and
we can fix it up together.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In the version of clang-format I've got locally[0],
WhitespaceSensitiveMacros seems to only work sometimes. That means that
if we ever run it on some particular things, it could seriously mess up
a bunch of our debugging output. That's not great.
In this patch, I've gone ahead and run clang-format on all the macros
that use __LINE__, which are the obvious places this is dangerous, and
then audited the result and fixed anything that's broken (including a
couple of places where it was already broken.)
[0] random:~/devel/github.com/shim/clang-format$ clang-format --version
clang-format version 11.0.0 (Fedora 11.0.0-2.fc33)
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream: pr#212
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This is a preparation commit for removing the setup_console(1) calls from
MokManager and shim so that we don't force the EFI console to switch to
text-mode.
This commit replaces all direct calls to Print / PrintAt with calls to
the new helpers (no functional changes) so that we can delay calling
setup_console(1) till the first Print call in a follow-up patch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
I'm pretty done with typing uefi_call_wrapper() and counting arguments
every time. Instead, just make the compiler error if we don't have
ms_abi. Also, make it so nothing can use uefi_call_wrapper() directly.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
If we open it, we have to close it.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Also consistently name our status variable "efi_status" unless there's a
good reason not to, such as already having another one of those.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Covscan believes all this stuff:
852 bs = 0;
853 rc = uefi_call_wrapper(fh2->Read, 3, fh2, &bs, NULL);
7. Condition rc == (9223372036854775813UL /* 0x8000000000000000UL | 5 */), taking false branch.
8. Condition rc == 0, taking false branch.
15. Condition rc == (9223372036854775813UL /* 0x8000000000000000UL | 5 */), taking false branch.
16. Condition rc == 0, taking true branch.
17. Condition bs != 0, taking true branch.
30. Condition rc == (9223372036854775813UL /* 0x8000000000000000UL | 5 */), taking false branch.
31. Condition rc == 0, taking false branch.
854 if (rc == EFI_BUFFER_TOO_SMALL ||
855 (rc == EFI_SUCCESS && bs != 0)) {
856 buffer = AllocateZeroPool(bs);
18. Condition !buffer, taking false branch.
857 if (!buffer) {
858 Print(L"Could not allocate memory\n");
859 /* sure, this might work, why not? */
860 uefi_call_wrapper(fh2->Close, 1, fh2);
861 uefi_call_wrapper(fh->Close, 1, fh);
862 return EFI_OUT_OF_RESOURCES;
863 }
864
865 rc = uefi_call_wrapper(fh2->Read, 3, fh2, &bs, buffer);
866 }
9. Condition bs == 0, taking false branch.
19. Condition bs == 0, taking false branch.
32. Condition bs == 0, taking false branch.
867 if (bs == 0)
868 break;
869
10. Condition (INTN)rc < 0, taking false branch.
20. Condition (INTN)rc < 0, taking false branch.
33. Condition (INTN)rc < 0, taking false branch.
870 if (EFI_ERROR(rc)) {
871 Print(L"Could not read \\EFI\\: %d\n", rc);
872 if (buffer) {
873 FreePool(buffer);
874 buffer = NULL;
875 }
876 uefi_call_wrapper(fh2->Close, 1, fh2);
877 uefi_call_wrapper(fh->Close, 1, fh);
878 return rc;
879 }
34. alias_transfer: Assigning: fi = buffer.
880 EFI_FILE_INFO *fi = buffer;
881
11. Condition !(fi->Attribute & 16), taking false branch.
21. Condition !(fi->Attribute & 16), taking false branch.
CID 182858 (#1-3 of 3): Explicit null dereferenced (FORWARD_NULL)35. var_deref_op: Dereferencing null pointer fi.
882 if (!(fi->Attribute & EFI_FILE_DIRECTORY)) {
883 FreePool(buffer);
884 buffer = NULL;
885 continue;
886 }
Because it doesn't know that when bs==0, fh2->Read() will return
EFI_BUFFER_TOO_SMALL and set bs to the size we need to allocate, so the
allocation path is always taken. Instead, handle our exit/error paths
directly there, and make the allocation path nonconditional.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Covscan sez:
720 FreePool(buffer);
assignment: Assigning: buffer = NULL.
721 buffer = NULL;
722
723 CHAR16 *bootcsv=NULL, *bootarchcsv=NULL;
724
725 bs = 0;
726 do {
727 bs = 0;
728 rc = uefi_call_wrapper(fh->Read, 3, fh, &bs, NULL);
729 if (EFI_ERROR(rc) && rc != EFI_BUFFER_TOO_SMALL) {
730 Print(L"Could not read \\EFI\\%s\\: %d\n", dirname, rc);
null: At condition buffer, the value of buffer must be NULL.
dead_error_condition: The condition buffer cannot be true.
731 if (buffer)
CID 182851 (#1 of 1): Logically dead code (DEADCODE)dead_error_line:
Execution cannot reach this statement: FreePool(buffer);.
732 FreePool(buffer);
733 return rc;
734 }
And it's right; buffer can never be non-NULL there. So just take that
out.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Covscan believes the following:
782 if ((EFI_ERROR(rc) || !bootarchcsv) && bootcsv) {
783 EFI_FILE_HANDLE fh2;
784 rc = uefi_call_wrapper(fh->Open, 5, fh, &fh2,
785 bootcsv, EFI_FILE_READ_ONLY, 0);
786 if (EFI_ERROR(rc) || fh2 == NULL) {
787 Print(L"Couldn't open \\EFI\\%s\\%s: %d\n",
788 dirname, bootcsv, rc);
789 } else {
CID 182829 (#1 of 1): Unused value (UNUSED_VALUE)returned_value:
Assigning value from try_boot_csv(fh2, dirname, bootcsv) to rc here,
but that stored value is overwritten before it can be used.
790 rc = try_boot_csv(fh2, dirname, bootcsv);
791 uefi_call_wrapper(fh2->Close, 1, fh2);
792 }
793 }
value_overwrite: Overwriting previous write to rc with value 0UL.
794 rc = EFI_SUCCESS;
795
796 return rc;
797}
Which isn't untrue, we just don't happen to be using the return code for
anything, before we intentionally return success to our caller.
So that's annoying, but whatever. Just print the error as well.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Covscan says:
146 UINTN len = 0;
147 CHAR16 *b = NULL;
2. tainted_data_argument: Calling function get_file_size taints argument len.
148 rc = get_file_size(fh2, &len);
3. Condition (INTN)rc < 0, taking false branch.
149 if (EFI_ERROR(rc)) {
150 uefi_call_wrapper(fh2->Close, 1, fh2);
151 return rc;
152 }
153
4. overflow_assign: Assigning overflowed or truncated value (or a value computed from an overflowed or a truncated value) to b.
8. overflow: Add operation overflows on operands len and 2UL. Example value for operand: len = 18446744073709551614.
154 b = AllocateZeroPool(len + 2);
Technically we can't handle a file larger than 0xfffffffffffffffd (on
x86_64) because when we try to allocate the buffer to hold it with a
trailing UCS-2 NUL we overflow to 0. Also our filesystem can't hold a
file bigger than 4GB... So this is probably actually broken on 32-bit
platforms.
This patch limits it to some handy amount like 1024 * PAGE_SIZE, aka
4MB.
Note that this doesn't appear to be exploitable (at least on edk2-based
firmwares), because AllocateZeroPool() has a minimum granularity of 1
page, so even if you overflow it with a 4GB file, we'll get 1 page out
of it and then try to read 1 byte into it, and then it's just going to
be a parse error on the CSV. Even if we error on the sentinal UCS-2 NUL
we put at the end, it'll still be inside of the zeroed page, and it still
won't fault or overwrite any meaningful data.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
At all the places we use fh->GetInfo, covscan can't tell that
fh->GetInfo() will return EFI_BUFFER_TOO_SMALL and we'll allocate on the
first try.
If we just explicitly check for "buffer == NULL" as well, covscan
believes we're doing work we don't need to (which is true!)
So instead, put an rc test to return error for everything else there, so
the allocation isn't in a conditional.
Yet another stupid one, but it's easier to nerf it this way than write
the false-positive rule, and it also hardens against incorrect UEFI
implementations (though we've not seen any yet with the problem this
avoids).
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
AMI BIOS (e.g, Intel NUC5i3MYHE) may automatically hide and patch BootXXXX
variables with ami_masked_device_path_guid.
Initially, the normal boot option created by fallback looks like this:
00000000 01 00 00 00 5e 00 42 00 6f 00 6f 00 74 00 6c 00 |....^.B.o.o.t.l.|
00000010 6f 00 61 00 64 00 65 00 72 00 20 00 54 00 65 00 |o.a.d.e.r. .T.e.|
00000020 73 00 74 00 20 00 28 00 36 00 34 00 2d 00 62 00 |s.t. .(.6.4.-.b.|
00000030 69 00 74 00 29 00 00 00 04 01 2a 00 01 00 00 00 |i.t.).....*.....|
00000040 00 08 00 00 00 00 00 00 00 00 08 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 01 01 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 |....0.\.E.F.I.\.|
00000070 42 00 4f 00 4f 00 54 00 5c 00 74 00 65 00 73 00 |B.O.O.T.\.t.e.s.|
00000080 74 00 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 |t.x.6.4...e.f.i.|
00000090 00 00 7f ff 04 00 |......|
00000096
after reboot, fallback has to create a new one due to the previous boot
option is hidden and masked by AMI BIOS:
00000000 09 00 00 00 76 00 42 00 6f 00 6f 00 74 00 6c 00 |....v.B.o.o.t.l.|
00000010 6f 00 61 00 64 00 65 00 72 00 20 00 54 00 65 00 |o.a.d.e.r. .T.e.|
00000020 73 00 74 00 20 00 28 00 36 00 34 00 2d 00 62 00 |s.t. .(.6.4.-.b.|
00000030 69 00 74 00 29 00 00 00 01 04 14 00 e7 75 e2 99 |i.t.)........u..|
00000040 a0 75 37 4b a2 e6 c5 38 5e 6c 00 cb 7f ff 04 00 |.u7K...8^l......|
00000050 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 |..*.............|
00000060 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 01 01 04 04 30 00 5c 00 |............0.\.|
00000080 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 |E.F.I.\.B.O.O.T.|
00000090 5c 00 74 00 65 00 73 00 74 00 78 00 36 00 34 00 |\.t.e.s.t.x.6.4.|
000000a0 2e 00 65 00 66 00 69 00 00 00 7f ff 04 00 |..e.f.i.......|
000000ae
And after several reboot, fallback will have to create more boot options
because AMI BIOS corrupts the previous ones.
We can get the valid device path if just skipping the masked device path and
its next end path.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
|
|
If the boot option recorded in csv is not in a media device path, the
corresponding full device path will be referred for creating the boot
variable.
However, the current code logic always frees the full device path
(full_device_path) and the media device path (dp) separately. In order
to resolve this issue, always check whether dp equals to full_device_path
before freeing dp.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
|
|
Since booting the entry with fallback in the stack of things that got
measured will result in all the wrong PCR values, in the cases where TPM
is present and enabled, use ->Reset() instead of loading the Boot####
variable and executing its target.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Rob Clark noticed while, implementing a UEFI like backend on u-boot,
that if a File Handle actually returns a meaningful device path from
DevicePathFromHandle(), we wind up with a horribly wrong device path in
the boot variable. He's right, normal UEFI doesn't return that, which
means FileDevicePath() in our code currently does nothing at all.
Instead of all that, pass in the device's handle, and it'll do what
we're doing after the fact there.
Here's the log from a current run:
FS0:\> \efi\BOOT\BOOTX64.EFI
System BootOrder not found. Initializing defaults.
find_boot_options:778:Found directory named "fedora"
try_boot_csv:532:Found file "\EFI\fedora\BOOT.CSV"
try_boot_csv:544:File looks like:
?shim.efi,Fedora,,This is the boot entry for Fedora
populate_stanza:495:CSV data: "shim.efi,Fedora,,This is the boot entry for Fedora"
populate_stanza:501:filename: "shim.efi"
populate_stanza:508:label: "Fedora"
populate_stanza:514:arguments: ""
add_to_boot_list:430:file DP: PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi
FindSubDevicePath:78:input device path: "PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
FindSubDevicePath:86:sub-path (4,1): "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
add_to_boot_list:452:04 01 2A 00 01 00 00 00 00 08 00 00 00 00 00 00
add_to_boot_list:452:00 40 06 00 00 00 00 00 2A 27 84 65 B9 D7 2A 44
add_to_boot_list:452:B8 A4 19 B5 EC 45 66 F4 02 02 04 04 2E 00 5C 00
add_to_boot_list:452:45 00 46 00 49 00 5C 00 66 00 65 00 64 00 6F 00
add_to_boot_list:452:72 00 61 00 5C 00 73 00 68 00 69 00 6D 00 2E 00
add_to_boot_list:452:65 00 66 00 69 00 00 00 7F FF 04 00
add_to_boot_list:459:device path: "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
Creating boot entry "Boot0000" with label "Fedora" for file "\EFI\fedora\shim.efi"
AddOption - Boot0000, then CurrentCount = 0x00000008
update_boot_order:390:nbootorder: 7
BootOrder: 0000 0002 0001 0003 0005 0006 0004
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
When dir->Read() says bs=0, we shouldn't try to allocate a buffer and
read into it. On edk2 this works because there's an implicit (possibly
accidental) minimum size of one pool list entry that can be allocated,
so you wind up getting (I think) 8 bytes.
When Rob Clark tried to run this under uboot's emulated UEFI
environment, dir->Read() returned 0 and when we passed that to
AllocateZeroPool() less good things happened.
So just check for that case and exit appropriately.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
