summaryrefslogtreecommitdiff
path: root/mok.c
diff options
context:
space:
mode:
authorJavier Martinez Canillas <javierm@redhat.com>2021-03-17 10:09:24 +0100
committerPeter Jones <pjones@redhat.com>2021-03-18 22:47:43 -0400
commit937afbe9e63fa88d80b10874d682bf30776f4e71 (patch)
tree2c6017fc1aee03d94e38388ac3e443a64983d819 /mok.c
parent0ff04b2ff2bc2c5ebe6bbb97aa89fb7ae8c318ac (diff)
downloadefi-boot-shim-937afbe9e63fa88d80b10874d682bf30776f4e71.tar.gz
efi-boot-shim-937afbe9e63fa88d80b10874d682bf30776f4e71.zip
shim: Use the default loader if an EFI_LOAD_OPTION can't be parsed
If the LoadOptions string count is zero, then it's assumed that it is an EFI_LOAD_OPTION and the OptionalData field attempt to be parsed. If that fails as well, in the second stage was set to the default loader path. But this behaviour was changed by the commit 018b74d2 ("shim: attempt to improve the argument handling"), and not in that case the LoadOptions is attempted to be used as a single string. This breaks some firmwares that return something in the LoadOptions but are not a proper EFI device path. Instead of making assumptions about the LoadOptions if can't be parsed correctly, just use the default loader as it was done before that commit. This fixes booting on a Gigabyte GA-Z97X-SLI mainboard that contains the following bytes as LoadOptions: 0x41 0x4d 0x42 0x4f ('AMBO'). Reported-by: Thomas Frauendorfer | Miray Software <tf@miray.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Diffstat (limited to 'mok.c')
0 files changed, 0 insertions, 0 deletions