rhboot / shim Goto Github PK
View Code? Open in Web Editor NEWUEFI shim loader
License: Other
UEFI shim loader
License: Other
In function store_keys wouldn't it be better to change this part of code:
if (pw_length < 8) {
Print(L"At least %d characters for the password\n",
PASSWORD_MIN);
}
into this:
if (pw_length < PASSWORD_MIN) {
Print(L"At least %d characters for the password\n",
PASSWORD_MIN);
}
Because when the minimum password length does change in the future, you wouldn't have a problem with this if-clause.
Line 2531 in e06765a
Hi @vathpela , may I ask about the function "set_second_stage" in shim.c ?
If the LoadOption data happens to be L"\0" , what's the expected results?
I found that the function "count_ucs2_strings" returns 1, when the input is L"\0".
In such a case, do we want to fall back to DEFAULT_LOADER? Or halt?
Hi all,
I'm currently experimenting with booting Xen through the latest version of shim and I've ran into a couple issue. First, the line That actually didn't do what I thought it did, the firmware just fall back to another Xen entry, that's why Xen couldn't find the shim.li->ImageBase = buffer;
makes xen.efi throw up with "Unsupported relocation type" errors. The relocation types Xen complained about were quite obviously nonsensical and with the ImageBase not being fixed up by shim Xen seems to be able to get pass that problem. However, it is unable to locate the shim protocol with the guid afterwards. Does anyone have any pointers on what might be going wrong?
So the problem that I have is that if I boot xen.efi through the shim, Xen complains about "Unsupported relocation type". I had it print the relocation type it finds for the section and it does look nonsensical (like 13). Anyone has any tips on what might be going wrong?
Thanks!
I've complile and test shim 0.2/0.3/0.7,and shim works fine.
but I complile shim 0.8 then test it in vmware, the vmware halt.
My gcc version:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/libexec/gcc/x86_64-linux-gnu/4.7.4/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/usr/local/gcc --enable-shared --enable-linker-build-id --without-included-gettext --enable-threads=posix --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-plugin --with-system-zlib --disable-browser-plugin --with-arch-directory=amd64 --enable-multiarch --disable-werror --with-arch-32=i686 --disable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (GCC)
After shim refuses to load a chained bootloader, and a corresponding key is enrolled via shim's menu, “Continue boot” does not result in another attempt to load, but instead exits shim. On real hardware this typically results in a failed boot error from the BIOS, leaving the user puzzled about whether the key they enrolled is the correct one. After a reboot everything works, but shim could be a bit more user-friendly in this regard, I think.
I'm trying to get UEFI netboot (PXE) working with secure boot. My plan is simply:
I intend to use a custom signed grub2, so it won't fit the built-in key of shim.efi. I think shim.efi should call MokManager if grubx64.efi is invalid, so it give my user a chance to add my key.
But tftp log suggests that shim.efi never tries to fetch MokManager.efi from TFTP server (it does load grubx64.efi). After failing to verify grubx64.efi, it displays a dos style blue screen with following message:
ERROR
Verification failed: (15) Access Denied
______
| OK |
------
I googled it and cannot find any useful infomation about it. Can you explain the reason of the error, thanks.
I've tried shim 0.8 from Ubuntu and Fedora.
I am using Ubuntu 14.04 x86_64. The version of make is 3.81.
I get the following error when compile:
Fatal error: can't create Hash/CryptMd4Null.o: No such file or directory
Analyse the reason:
ls -l Cryptlib/
total 4
drwxrwxr-x 2 tanminger tanminger 4096 Aug 21 02:34 {Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}
$
In Makefile line 105:
mkdir -p Cryptlib/{Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}
This command should has issue.
I have a ThinkPad X220 Tablet which runs Fedora 23 with automatic updates,
Chromium and Spotify Copr. Up until Friday night, 2016-03-19, it worked just
fine.
Friday afternoon the new Kernel 4.4.5 was installed. It was only loaded
on Saturday when I started the machine in the afternoon. I suspended the
laptop to RAM and found that it did not woke up. I only got this strange
light show:
https://www.youtube.com/watch?v=ajoWfCtk7yE
The error (sadly) is 100% reproducible. I then went on and started with the
earlier kernels, 4.4.4 and 4.4.3, which worked fine before Friday. The error is
just the same, it does not wake up.
Then I also started a Kubuntu 15.04 from USB and had a slightly
different error. The machine would start the fan and the power light
would turn on, but the wifi was still off and the screen was black.
Using Arch Linux 2016.03.01 I was able to reproduce the error with
Kernel 4.4.1. Therefore I think it is not about the software any more.
This might be somewhere in the hardware or UEFI firmware.
On the fedora-devel mailinglist I posted the above and got some valuable
feedback. In the meantime I noticed that I could not save anything in the UEFI.
It looks like this:
I tried to do an UEFI firmware upgrade using the boot CD images that Lenovo
provides. They are 16-bit DOS and my boot sequence was locked into UEFI only
.
Therefore I had to boot a Windows and do the upgrade there. This did not change
much, I did not get any error message in the UEFI/BIOS but it would just freeze
when trying to save something.
Chris Murphy from the fedora-devel list suggested to look at the output of
efibootmgr -v
. Currently it looks like the following:
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 004A,000A,0009,0006,0007,0008,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0004 ME Configuration Menu FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0006* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0007* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot0009* ATA HDD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B* ATA HDD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000D* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000E* ATAPI CD1 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35403)
Boot000F* ATAPI CD2 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010 Other CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011* ATA HDD3 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f603)
Boot0012* ATA HDD4 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0013 Other HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0014* IDER BOOT CDROM PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0015* IDER BOOT Floppy PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0016* ATA HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0017* ATAPI CD: VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0018* PCI LAN VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot0019* kubuntu HD(1,GPT,9feb65d0-1f99-4f66-8cc1-1e2aa3c71354,0x800,0xf3800)/File(\EFI\kubuntu\shimx64.efi)
Boot001A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot001B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot001C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot001D* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot001E* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot001F* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0020* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0021* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0022* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0023* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0024* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0025* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0026* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0027* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0028* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0029* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002D* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002E* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot002F* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0030* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0031* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0032* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0033* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0034* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0035* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0036* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0037* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0038* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0039* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003B* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003C* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003D* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003E* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot003F* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0040* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0041* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0042* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0043* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0044* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0045* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0046* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0047* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0048* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0049* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot004A* Fedora HD(1,GPT,18add345-44b0-44dd-9aa9-feae671b7d2e,0x800,0x64000)/File(\EFI\fedora\shim.efi)
By his suggestion, I deleted a lot of the boot entries. He said that this might
be NVRAM corruption. The first delete that I tried using efibootmgr
failed as
it complained about lack of free memory. So some hard limit has been reached
there. Deleing it via the efivars
file system helped, and then I could delete
the remainder with efibootmgr
.
He further suggested to delete everything in EFI/BOOT/
and run dnf reinstall shim grub2-efi
, which I did as well as grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
. After that, the checksum of
/boot/efi/EFI/BOOT/BOOTX64.EFI
has not changed, though.
After I deleted the boot entries, I could make changes in the UEFI/BIOS screen
again. Also the laptop consistently wakes up from the suspend again.
As a workaround, I wrote a little script that deletes the Fedora
boot entries
once there are over fifty.
In case it is of any interest, this is the output of lsblk
:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 500M 0 part /boot
└─sda3 8:3 0 465,1G 0 part
└─luks-3f530000-b2c3-4ba3-9e85-1a96494cc25d 253:0 0 465,1G 0 crypt
├─fedora_martin--friese-root 253:1 0 50G 0 lvm /
├─fedora_martin--friese-swap 253:2 0 7,8G 0 lvm [SWAP]
└─fedora_martin--friese-home 253:3 0 407,3G 0 lvm /home
I am not sure whether this is the right place to report this bug. Is this
something which could be fixed withing this project?
MokSBStateRT doesn't seem to be getting mirrored correctly (not showing up at all) with shim 15.
Hello,
by reading the source code, it appears to me that the shim checks the black-list databases only for SHA-256 hashes.
So if MS or an OEM inserts a hash (into a blacklist) generated ONLY with a hash algorithm other than SHA-256 (for example only with SHA-512, but not with SHA-256) the shim will not "see" the black-listed hash and will execute a black-listed binary or a binary signed with the black-listed cert.
Thus, the shim would execute untrusted code, which could lead to the shim being black-listed or Fedora cert to be black-listed by MS or OEM.
I guess this comment in shim.c might be related to this issue: "FIXME: Check which kind of hash". I also guess this comment has been forgotten about because this issue is not in the TODO file.
SHA-256 seems to be hard-wired, while SHA-512 is completely ignored. Why?
Line 2139 in e563bc3
The strlen(dppath) always return 1.
The dppath and PathName always starts with "\", so the StrnCaseCmp() always returns 0 and is_our_path() always return 1.
Rootcause should be strlen uses char*, but the dppath is CHAR16 *
Replace strlen() with StrLen() could fix this issue.
When shim is invoked as e.g. \EFI\BOOT\BOOTx64.EFI, it correctly determines the location of grubx64.efi and MokManager.efi. However, if it is invoked from the EFI Shell without the leading backslash, or from inside EFI\BOOT directory as just BOOTx64.EFI, it is confused, tries to add forward slashes (which UEFI does not recognize), looks in upper-level directory instead, etc. A minor issue, but who knows — some UEFI firmware might decide to e.g. use pathes that don't start with a backslash.
I recently updated my version of shim from 0.8 to version 13 and noticed that on every boot shim prints two lines on screen, stating its path and the argument shimx64.efi is called with.
Lines 2088 to 2089 in 91229b7
To me this looks like some leftover debug output, or troubleshoot information for people with weird EFI implementations. Is this intentional? Is there no way to disable this output other than recompiling shim?
(Note: I use a signed version of shim from Ubuntu, but I report it here because it's clearly an upstream issue)
When I boot my host from pxe server, pxe client download shim from tftp server successful, but shim failed to fetch netimage with error message like:
Unable to fetch tftp image: TFTP Error, start_image returned tftp error
Not sure how to submit a patch so I'll just drop the patch here. This adds the ability to check the signature of 32bit binaries from x64 EFI and perhaps 64bit binaries from x32 EFI. Specifically to be able to boot only signed 32bit linux kernel via grub with safeboot enabled. Also found an error where you're checking for NULL on something that will never be NULL but certsize could be zero (which would happen with a signed kernel but the signature was off a different key). It's based off of
shim-76f8050ff6003e6048fdc4430d8b503aff934255
shim.c | 146 ++++++++++++++++++++++++++++++++++++++++-------------------------
1 file changed, 90 insertions(+), 56 deletions(-)
diff --git a/shim.c b/shim.c
index ea8eba8..58eabb3 100644
--- a/shim.c
+++ b/shim.c
@@ -134,11 +134,26 @@ static EFI_STATUS relocate_coff (PE_COFF_LOADER_IMAGE_CONTEXT *context,
int size = context->ImageSize;
void *ImageEnd = (char *)data + size;
-#if LP64
#if **LP64**
context->PEHdr->Pe32Plus.OptionalHeader.ImageBase = (UINT64)data;
#else
perror(L"Loaded Image must be x86\n");
return EFI_UNSUPPORTED;
#endif
#if **LP64**
perror(L"Loaded Image must be x64\n");
return EFI_UNSUPPORTED;
#else
context->PEHdr->Pe32.OptionalHeader.ImageBase = (UINT32)data;
#endif
perror(L"Unknown PE format\n");
return EFI_UNSUPPORTED;
if (context->NumberOfRvaAndSizes <= EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
perror(L"Image has no relocation entry\n");
@@ -577,15 +592,21 @@ static EFI_STATUS generate_hash (char *data, int datasize_in,
}
/* Hash end of certificate table to end of image header */
-#if LP64
(int) ((char *) (&context->PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1]) - data);
(int) ((char *) (&context->PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1]) - data);
hashbase = (char *) &context->PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1];
hashsize = context->PEHdr->Pe32Plus.OptionalHeader.SizeOfHeaders -
(int) ((char *) (&context->PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1]) - data);
hashbase = (char *) &context->PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1];
hashsize = context->PEHdr->Pe32.OptionalHeader.SizeOfHeaders -
(int) ((char *) (&context->PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY + 1]) - data);
perror(L"Unknown PE format\n");
status = EFI_UNSUPPORTED;
goto done;
if (!(Sha256Update(sha256ctx, hashbase, hashsize)) ||
!(Sha1Update(sha1ctx, hashbase, hashsize))) {
@@ -595,11 +616,13 @@ static EFI_STATUS generate_hash (char *data, int datasize_in,
}
/* Sort sections */
-#if LP64
SumOfBytesHashed = context->PEHdr->Pe32Plus.OptionalHeader.SizeOfHeaders;
// must be 32 bit header
SumOfBytesHashed = context->PEHdr->Pe32.OptionalHeader.SizeOfHeaders;
/* Validate section locations and sizes /
for (index = 0, SumOfSectionBytes = 0; index < context->PEHdr->Pe32.FileHeader.NumberOfSections; index++) {
@@ -687,14 +710,13 @@ static EFI_STATUS generate_hash (char *data, int datasize_in,
/ Hash all remaining data */
if (datasize > SumOfBytesHashed) {
hashbase = data + SumOfBytesHashed;
hashsize = (unsigned int)(
datasize -
-#if LP64
context->PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY].Size -
-#else
context->PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY].Size -
-#endif
SumOfBytesHashed);
if (context->PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
hashsize = (unsigned int)(datasize -context->PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY].Size - SumOfBytesHashed);
}
else {
hashsize = (unsigned int)(datasize -context->PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY].Size - SumOfBytesHashed);
}
if (!(Sha256Update(sha256ctx, hashbase, hashsize)) ||
!(Sha1Update(sha1ctx, hashbase, hashsize))) {
@@ -820,16 +842,17 @@ static EFI_STATUS verify_buffer (char *data, int datasize,
return status;
}
/*
* And finally, check against shim's built-in key
*/
if (AuthenticodeVerify(cert->CertData,
context->SecDir->Size - sizeof(cert->Hdr),
vendor_cert, vendor_cert_size, sha256hash,
SHA256_DIGEST_SIZE)) {
status = EFI_SUCCESS;
return status;
if (vendor_cert_size) {
if (AuthenticodeVerify(cert->CertData,
context->SecDir->Size - sizeof(cert->Hdr),
vendor_cert, vendor_cert_size, sha256hash,
SHA256_DIGEST_SIZE)) {
status = EFI_SUCCESS;
return status;
}
}
@@ -855,17 +878,24 @@ static EFI_STATUS read_header(void *data, unsigned int datasize,
if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE)
PEHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)((char *)data + DosHdr->e_lfanew);
-#if LP64
if (PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
context->NumberOfRvaAndSizes = PEHdr->Pe32Plus.OptionalHeader.NumberOfRvaAndSizes;
context->SizeOfHeaders = PEHdr->Pe32Plus.OptionalHeader.SizeOfHeaders;
context->ImageSize = PEHdr->Pe32Plus.OptionalHeader.SizeOfImage;
OptHeaderSize = sizeof(EFI_IMAGE_OPTIONAL_HEADER64);
}
else if (PEHdr->Pe32.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
context->NumberOfRvaAndSizes = PEHdr->Pe32.OptionalHeader.NumberOfRvaAndSizes;
context->SizeOfHeaders = PEHdr->Pe32.OptionalHeader.SizeOfHeaders;
context->ImageSize = (UINT64)PEHdr->Pe32.OptionalHeader.SizeOfImage;
OptHeaderSize = sizeof(EFI_IMAGE_OPTIONAL_HEADER32);
}
else {
perror(L"Unknown PE format\n");
return EFI_UNSUPPORTED;
}
context->NumberOfSections = PEHdr->Pe32.FileHeader.NumberOfSections;
if (EFI_IMAGE_NUMBER_OF_DIRECTORY_ENTRIES < context->NumberOfRvaAndSizes) {
@@ -913,17 +943,21 @@ static EFI_STATUS read_header(void *data, unsigned int datasize,
}
context->PEHdr = PEHdr;
-#if LP64
context->ImageAddress = PEHdr->Pe32Plus.OptionalHeader.ImageBase;
context->EntryPoint = PEHdr->Pe32Plus.OptionalHeader.AddressOfEntryPoint;
context->RelocDir = &PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC];
context->SecDir = (EFI_IMAGE_DATA_DIRECTORY *) &PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY];
-#else
context->ImageAddress = PEHdr->Pe32.OptionalHeader.ImageBase;
context->EntryPoint = PEHdr->Pe32.OptionalHeader.AddressOfEntryPoint;
context->RelocDir = &PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC];
context->SecDir = (EFI_IMAGE_DATA_DIRECTORY *) &PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY];
-#endif
if (context->PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {
context->ImageAddress = PEHdr->Pe32Plus.OptionalHeader.ImageBase;
context->EntryPoint = PEHdr->Pe32Plus.OptionalHeader.AddressOfEntryPoint;
context->RelocDir = &PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC];
context->SecDir = (EFI_IMAGE_DATA_DIRECTORY *) &PEHdr->Pe32Plus.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY];
}
else {
// must be x32 header
context->ImageAddress = PEHdr->Pe32.OptionalHeader.ImageBase;
context->EntryPoint = PEHdr->Pe32.OptionalHeader.AddressOfEntryPoint;
context->RelocDir = &PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC];
context->SecDir = (EFI_IMAGE_DATA_DIRECTORY *) &PEHdr->Pe32.OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY];
}
context->FirstSection = (EFI_IMAGE_SECTION_HEADER *)((char *)PEHdr + PEHdr->Pe32.FileHeader.SizeOfOptionalHeader + sizeof(UINT32) + sizeof(EFI_IMAGE_FILE_HEADER));
if (context->ImageSize < context->SizeOfHeaders) {
Package: shim-x64-12-1.el7.centos.x86_64
Not sure this is the right place to bug report or if this belongs with the package maintainers - let me know.
Per https://github.com/rhboot/shim/blob/master/README.fallback
" if the boot variables are missing or corrupted,
the firmware will eventually try to boot the hard disk as removable
media. In that case, it'll invoke \EFI\BOOT\BOOTX64.EFI (or whatever
filename is right for your architecture.) In that case it'll be in
\EFI\BOOT, so it'll check for fallback.efi , and it'll find it and run
it."
shim-x64-12-1.el7.centos.x86_64 ships with /boot/efi/EFI/BOOT/fbx64.efi and /boot/efi/EFI/BOOT/BOOTX64.EFI
BOOTX64.EFI still tries to fall back to fallback.efi , which no longer exists, as it seems to have been renamed to fbx64.efi.
Renaming fbx64.efi to fallback.efi returns to expected behaviour (a-la previous shim rpm).
With no fallback.efi on an already installed system, we end up cycling through the fallback list and failing on the last try, ./grubx64.efi, which is not there:
fs0:> EFI\BOOT\BOOTX64.EFI
Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found
Loading fbx64.efi directly performs expected behaviour:
fs0:> EFI\BOOT\fbx64.efi
System BootOrder not found. Initializing defaults.
Creating boot entry "Boot0000" with label "CentOS Linux" for file "\EFI\centos\shimx64.efi"
I do not see the string "fbx64" in this shim repo, so I assume this naming is being generated elsewhere (per-distribution rpm spec file?). If it is preferred to simply add fbx64.efi to the fallback list, let me know and i'll submit a PR.
Thanks
Hello,
when I try to compile with "make EFIDIR = (path) install" shim get this error:
shim.h: 27: 17: fatal error: efi.h: No such file or directory
I think I forgot my password, I tried mokutil --clear-password, or mokutil --reset, each time at reboot I get a "Password doesn't match".
I there a way to reset password ?
I'm on Fedora 28 with
shim-x64-15-2.x86_64
mokutil-1:0.3.0-8.fc28.x86_64
I ran mokutil --reset with a very recent mokutil, using SHIM 15+ snapshot (3beb971).
After rebooting and using the Reset MOK option in MokManager, the embedded certificate is no longer listed in mokutil --list-enrolled; in /proc/keys, etc.
MokListRT is empty.
os: ubuntu 16.04 amd64
shim-15# make
sed -e "s,@@Version@@,14,"
-e "s,@@uname@@,Linux x86_64 x86_64 x86_64 GNU/Linux,"
-e "s,@@COMMIT@@,master,"
< /1111/shim-15/version.c.in > version.c
gcc -ggdb -O0 -fno-stack-protector -fno-strict-aliasing -fpic -fshort-wchar -Wall -Wsign-compare -Werror -fno-builtin -Werror=sign-compare -ffreestanding -std=gnu89 -I/usr/lib/gcc/x86_64-linux-gnu/5/include "-DDEFAULT_LOADER=L"\\grubx64.efi"" "-DDEFAULT_LOADER_CHAR="\\grubx64.efi"" -nostdinc -I/1111/shim-15/Cryptlib -I/1111/shim-15/Cryptlib/Include -I/usr/include/efi -I/usr/include/efi/x86_64 -I/usr/include/efi/protocol -I/1111/shim-15/include -iquote /1111/shim-15 -iquote /1111/shim-15 -mno-mmx -mno-sse -mno-red-zone -nostdinc -maccumulate-outgoing-args -m64 -DEFI_FUNCTION_WRAPPER -DGNU_EFI_USE_MS_ABI -DNO_BUILTIN_VA_FUNCS -DMDE_CPU_X64 -DPAGE_SIZE=4096 "-DEFI_ARCH=L"x64"" "-DDEBUGDIR=L"/usr/lib/debug/usr/share/shim/x64-14/"" -c -o shim.o shim.c
shim.c: In function ‘handle_image’:
shim.c:1302:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->AllocatePages(AllocateAnyPages, EfiLoaderCode,
^
shim.c:1302:15: note: each undeclared identifier is reported only once for each function it appears in
shim.c: In function ‘should_use_fallback’:
shim.c:1473:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->HandleProtocol(image_handle, &EFI_LOADED_IMAGE_GUID,
^
shim.c: In function ‘load_image’:
shim.c:1645:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->HandleProtocol(device, &EFI_SIMPLE_FILE_SYSTEM_GUID,
^
shim.c: In function ‘start_image’:
shim.c:1834:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->HandleProtocol(image_handle, &EFI_LOADED_IMAGE_GUID,
^
shim.c: In function ‘set_second_stage’:
shim.c:2114:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->HandleProtocol(image_handle, &LoadedImageProtocol,
^
shim.c: In function ‘install_shim_protocols’:
shim.c:2381:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->InstallProtocolInterface(&shim_lock_handle,
^
shim.c: In function ‘uninstall_shim_protocols’:
shim.c:2410:2: error: ‘gBS’ undeclared (first use in this function)
gBS->UninstallProtocolInterface(shim_lock_handle, &SHIM_LOCK_GUID,
^
shim.c: In function ‘efi_main’:
shim.c:2571:3: error: ‘gRT’ undeclared (first use in this function)
gRT->ResetSystem(EfiResetShutdown, EFI_SECURITY_VIOLATION,
^
: recipe for target 'shim.o' failed
make: *** [shim.o] Error 1
Hi,
shim 0.9 does not build on Solaris systems. I have attached some patches if anyone is interested. Sorry if this is not the right place to post.
Thanks,
Mat Troi
patches.tar.gz
the internal key for signing fb.efi and mm.efi should be optional, and shouldn't be created by default. It also should have a much, much better name than "Testing CA Certificate".
In shim-11, sometimes we get things like:
2 .reloc 0000000a 00000000000b2000 00000000000b2000 000acc00 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data.ident 000000e4 00000000000b3040 00000000000b3040 000ace40 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .data 000291e8 00000000000b4000 00000000000b4000 000ad200 2**5
CONTENTS, ALLOC, LOAD, DATA
This doesn't work with signtool.exe, which does the wrong thing with the misaligned section.
There doesn't appear to be a way to verify whether validation in shim is enabled or disabled (the state of MokSBState / MokSB) past a reboot after initially disabling validation, for instance.
This would allow users to run mokutil only when it's really required to enable or disable validation, rather than trying to apply a change that is already in effect.
I'm trying to enroll a new MOK, but it doesn't take effect even though none of the tools show any error. It may be a UEFI implementation bug, but the error checking in MokManager seems decent, so I'm not sure what could be failing.
OS: Fedora 27
HW: HP Elitebook 840 G2
BIOS: M71 v 1.21 (latest available)
efivar -l
mokutil --list-enrolled
does not show new MOK, only the existing Fedora Secure Boot CA key. The new MOK is no longer shown under --list-new and the MokNew/MokAuth vars are gone.We recently got a bug report(*) that shim/fallback was stuck in an infinite reset loop. It's because that the firmware seems to ignore the restored boot option and also provides TPM protocol.
One possible solution is to add a count down menu before resetting the system so that the user has the chance to stop system reset and choose to load the boot option directly. We could also set a NV variable to notify fallback.efi not to reset afterward.
This bug:
SecureBoot enabled causes Win 8 UEFI to not start from grub
https://bugzilla.redhat.com/show_bug.cgi?id=1170245
can be fixed with this patch:
https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch?expand=1
But shim needs to be resigned in order to make all of this possible somehow.
We use Dnsmasq to replay the network boot service (PXE and uEFI network boot), for PXE, the pxelinux.0 works. However, with uEFI, if the secure boot is enabled, it fails. This is due to this issue:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/thread.html#11125
Dnsmasq won't be able to relay the tftp service for uEFI netboot client. When we disable secure boot, and use the following command to create a grubx64.efi by embedding the tftp server, for example:
grub-mkimage -C xz -O x86_64-efi -o /tftpboot/nbi_img/bootx64.efi --prefix='(tftp)/grub-efi.cfg/' -c /tmp/grub-efi.tmp/grub-header.cfg normal tftp efinet chain echo net gzio xzio linux efi_gop efi_uga png gfxterm gfxterm_background gfxterm_menu serial part_gpt part_msdos boot multiboot progress search ext2 xfs reiserfs jfs hfsplus fat ntfs configfile test sleep tr reboot halt
The contents of /tmp/grub-efi.tmp/grub-header.cfg:
*****************************************************.
set prefix=(tftp,192.168.120.12)/grub-efi.cfg
echo "Grub CPU and platform: $grub_cpu, $grub_platform"
echo 'Network status: '
net_ls_cards
net_ls_addr
net_ls_routes
[snipped]
*****************************************************.
Then uEFI netboot client is able to get the required files (e.g. grubx64.efi, and unicode.pf2) from the tftp server 192.168.120.12.
How can we do the similar thing for shim if it's signed? Is that possible we can pass the tftp server to shim without recompiling and signing it?
Thank you very much.
there should be a config.h target
Hello.
I have problems with the EV embedded certificate.
The same things but with the self-signed certificate, made in Linux with openssl, work fine.
But Microsoft rejected Shim with self-signed embedded certificate.
Help with my problem, please.
PS: Source Shim v. 0.7
After a bootloader certificate is enrolled into shim, it always proceeds to load the chained bootloader, and the user has no opportunity to remove the enrolled key using shim menu. Exiting the bootloader exits directly to UEFI, not shim. Authenticated variables used by MokManager seem to persist through disabling / re-enabling Secure Boot on real hardware.
It would be great if the user had an opportunity to reach shim menu unconditionally. E.g., if the chained bootloader would return to shim (no idea if that's possible with UEFI API), or if shim waited a couple of seconds before loading the chained image, with the user having an opportunity to intervene.
On the two Dell laptops XPS 13 9360 and 9370 and with OVMF and QEMU the Grml live image cannot be started from a USB device.
The error on the Dell display is:
Reloc 0 block size 2756420659 is invalid
Relocation failed: Unsupported
Failed to load image: Unsupported
start_image() returned Unsupported
With OVMF I only get the first two lines.
Here is how you can reproduce this with QEMU.
Download the Grml ISO file, and follow How to run OVMF in the Wiki. I downloaded Gerd’s prebuilt images and extracted them.
Then I did mkdir hda-contents
and run QEMU with the command below.
qemu-system-x86_64 -enable-kvm -bios edk2.git/ovmf-x64/OVMF-pure-efi.fd -hda fat:hda-contents -net none -hdb ~/Downloads/grml64-full_sid_latest.iso
When building shim 0.7 on a Solaris system, I get the error "pesign: could not parse signature list in EFI binary", you can see longer output below. I am able to sign other efi binary with pesign, so the issue is not in pesign or my certificate, but it has to do with how my binary is built I guess. Has anyone seen this issue?
Output:
...
...
certutil -A -n 'my CA' -d certdb/ -t CT,CT,CT -i ca.crt
pk12util -d certdb/ -i shim.p12 -W "" -K ""
pk12util: PKCS12 IMPORT SUCCESSFUL
certutil -d certdb/ -A -i shim.crt -n shim -t u
Notice: Trust flag u is set automatically if the private key is present.
objcopy -j .text -j .sdata -j .data
-j .dynamic -j .dynsym -j .rel
-j .rela -j .reloc -j .eh_frame
-j .vendor_cert
--target=elf64-x86-64-sol2 MokManager.so MokManager.efi
objcopy -j .text -j .sdata -j .data
-j .dynamic -j .dynsym -j .rel
-j .rela -j .reloc -j .eh_frame
-j .debug_info -j .debug_abbrev -j .debug_aranges
-j .debug_line -j .debug_str -j .debug_ranges
--target=elf64-x86-64-sol2 MokManager.so MokManager.efi.debug
pesign -n certdb -i MokManager.efi -c "shim" -s -o MokManager.efi.signed -f
pesign: could not parse signature list in EFI binary
MS plans on forcing the requirement that the public certificates embedded in shim for self signed grub/kernels are EV type (see http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx )
Can the current shim version validate binaries that have been signed with an EV Certificate?
If not, what is required for that?
Fallback currently creates full device paths, e.g. paths that include the pci roots, rather than relative device paths including only disks. This means that the paths won't survive through disks being moved.
While this won't cause a failure — because fallback will be invoked again and create another new boot entry — it would be better for fallback to create device paths containing only the entry for the HD() device itself when that's appropriate.
Hi
Just wanted to make an announcement that I created a new branch: https://github.com/rusnikola/shim which enables native DLL compilation and completely removes any dependencies on gnu-efi, libgcc, etc. I added all required library functions (printf, memcpy, memset, StrCpy, StrCat, etc), changed Makefiles to use clang to compile PE/COFF DLLs. Then I also included the FwImage tool which I have ported long time ago from Windows to Linux/POSIX which converts DLL to EFI.
I have tested compilation for X64 and IA32; ARM/AArch64 should probably be OK. I have done some testing on X64.
One of the biggest advantages is that it uses official TianoCore headers rather than gnu-efi. Also, file sizes are greatly reduced now. Compiled files are truly PE/COFF per UEFI spec rather than ELFs hidden inside PE/COFF stubs. Compiled shim is now ~425Kb (instead of 1Mb) due to much better elimination of unused OpenSSL code during linking!
See all distinctive features below. If there is any interest to merge changes in one way or another to the main (official) branch, please let me know. (e.g., creating shim-experimental or something like this)
Make sure to use clang 7.0 or higher. Edit Makefiles accordingly to specify correct paths to clang and lld-link.
Note: It uses EFIAPI / MS ABI calling convention for all platforms other than IA32. For IA32, it uses -mregparm=3 -mrtd for internal functions and EFIAPI for external ones. To preserve backward compatibility when overriding security policy, it uses SysV calling convention for X64 for those 3 exported functions only.
Distinctive Features:
Requirements:
clang/llvm/lld 7.0.0+ (needs the -mno-stack-arg-probe flag)
Official binaries for various Linux distributions are available at
http://releases.llvm.org/download.html
I’d like to ask a question that how long dose shim take to get an audit ?Thanks very much !
Hello,
I am building Arch Linux live USB, and as it should be bootable on all BIOS/UEFI/UEFI SecureBoot machines, I installed the publicly signed shim from AUR. Everything works fine, I get the MokManager screen when booting, but when I choose my MOK.cer file to be enrolled, MokManager gives me this error:
Unsupported Format
Only DER encoded certificate (*.cer/der/crt) is supported
Well, I first thought that I had done some user error here when configuring shim. However, if I stick the exactly same USB stick into my friend's laptop (ASUS TP501U), it works correctly. For the exactly same USB stick it gives me this false error. My laptop is Lenovo X1 Carbon 5th gen (model 20HR006CMX).
This bugs me, is it a bug I've created myself or some bug in shim?
I created the keys with
$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer
as suggested in ArchWiki and then simply copied the MOK.cer to the USB.
hi
whenever I try to compile shim I get the following messages
shim.c: In function ‘handle_image’:
shim.c:1304:15: error: ‘gBS’ undeclared (first use in this function)
efi_status = gBS->AllocatePages(AllocateAnyPages, EfiLoaderCode,
this goes on a couple of times and then fails
Any suggestion on how to fix this issue?
OS: Ubuntu 16.04
gcc 4:5.3.1-1ubuntu1
errlog.c and mok.c say they are "Distributed under terms of the GPLv3 license".
I was wondering, since the overall project (and other files, from what I can see) is BSD licensed, if that was a mistake or if they were deliberately put under the GPLv3?
I have created shim.efi using the Makefile in https://github.com/rhboot/shim. Signed the generated shim.efi using the keys generated by openssl and the sbsign executable. (Command sbsign --key shim.key --cert shim.crt). I got the following warning message " warning: data remaining[1034752 vs 1159672]: gaps between PE/COFF sections?".
The generated efi did not pass the signature validation check in the new BIOS.
Hi,
I was playing with https://github.com/ipxe/shimdemo and tried to load a linux kernel without to interfere with the build in machine's UEFI Secure Boot Keys (PK,KEK,DB).
The boot chain looks like this:
shim.ms.efi
->shim.vendor1.efi
with VENDOR_CERT_FILE=vendor2.der ->ipxe.vendor2.efi
->vmlinuz.vendor2
The Trust chain looks like this:
shim.ms.efi
boots because the MS keys are embedded in the UEFI firmwareshim.vendor1.efi
boots because I added the vendor1.esl to the MokLis
ipxe.vendor2.efi
boots because I added the vendor2.der
inside shim.vendor1.efi
vmlinuz.vendor2
is not booting because of the error Bootloader has not verified loaded image
But if I boot for example a vendor2 key signed shell.vendor2.efi
instead of vmlinuz.vendor2
there is no Bootloader has not verified loaded image
error and I'm successfully booted a vendor2 signed UEFI shell.
Is this the desired behavior?
I'm unsure if this is a bug in shim, mokutil, or user error. I also filed a bug against mokutil here: https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1600452
Feel free to close the issue if you can determine that it's not related to Shim (although any hints on what might be causing it would be appreciated!)
Lenovo Thinkpad P50, fresh install of Ubuntu 16.04 64bit
$ apt-cache policy mokutil
mokutil:
Installed: 0.3.0-0ubuntu3
Candidate: 0.3.0-0ubuntu3
Version table:
*** 0.3.0-0ubuntu3 500
500 http://cn.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy shim
shim:
Installed: 0.8-0ubuntu2
Candidate: 0.8-0ubuntu2
Version table:
*** 0.8-0ubuntu2 500
500 http://cn.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status
(1) do not disable SecureBoot as suggested during the install.
(2) install virtualbox-5.0 from the virtualbox ppa (deb http://download.virtualbox.org/virtualbox/debian xenial contrib)
(3) Follow instructions here to manually sign the vboxdrv kernel module (https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur/768310#768310)
$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vboxdrv)
$ sudo mokutil --import MOK.der
(enter password)
(4) reboot, click "enroll mok", "continue", "yes", enter password, (screenshots here: https://sourceware.org/systemtap/wiki/SecureBoot)
new mok will be enrolled and I will be asked to reboot (several users from the original askubuntu answer indicated that these exact steps worked for them.
"Error: Failed to set variable: (2) Invalid Parameter"
efi_status = uefi_call_wrapper(RT->SetVariable, 5, db_name,
&shim_lock_guid,
EFI_VARIABLE_NON_VOLATILE
| EFI_VARIABLE_BOOTSERVICE_ACCESS
| EFI_VARIABLE_APPEND_WRITE,
MokNewSize, MokNew);
}
if (efi_status != EFI_SUCCESS) {
console_error(L"Failed to set variable", efi_status);
return efi_status;
}
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: mokutil 0.3.0-0ubuntu3
ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13
Uname: Linux 4.4.0-28-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Jul 9 18:56:59 2016
InstallationDate: Installed on 2016-07-08 (0 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: mokutil
UpgradeStatus: No upgrade log present (probably fresh install)
I have attached a patch file to shim-14 which fixes a possible memory leak and fix a section for the loading of x86 kernel on UEFI64. (I first submitted the loading x32 kernel with x64 shim years ago that peter jones implemented via ALLOW_32BIT_KERNEL_ON_X64 but a section was misunderstood and fixed in this patch). This also adds something we need that allows us to use a common shim for multiple UEFI utilities, this is implemented as a new option where it looks for a shimx64.dat (or shimia32.dat) file that can be placed in the directory with the shim and it would contain the Unicode path (z-term) of the second stage file, otherwise falls back to the default hard-coded name. The name in that file could be a full path if starts with \EFI\ otherwise it’s relative to where shim is.
Check it out, be nice if it was in the mainline (even if config option) in case we ever need to update the shim version in the future.
Note something I thought of, but not going to worry about it, load_image should probably abort if the file size is zero.
shim-14.patch.zip
For users with an encrypted boot partition, keeping an updated version the kernel in a fat fs may be problematic. It would be easier to just keep the hash instead of the kernel in a fs where MokManager could access it instead. Is it possible to enroll a hash without the file?
Hi,
When I try to build shim 0.7 on a Solaris system, I get the following error:
gcc -nostdlib -znocombreloc -shared -fPIC -Bsymbolic -L/root/secured2/gnu-efi-3.0u/gnuefi -L/root/secured2/root/X86_64/lib/ -LCryptlib -LCryptlib/OpenSSL /root/secured2/gnu-efi-3.0u/gnuefi/crt0-efi-x86_64.o shim.o -o shim
Text relocation remains referenced
against symbol offset in file
ImageBase 0x9 /root/secured2/gnu-efi-3.0u/gnuefi/crt0-efi-x86_64.o
_relocate 0x19 /root/secured2/gnu-efi-3.0u/gnuefi/crt0-efi-x86_64.o
efi_main 0x20 /root/secured2/gnu-efi-3.0u/gnuefi/crt0-efi-x86_64.o
_DYNAMIC 0x10 /root/secured2/gnu-efi-3.0u/gnuefi/crt0-efi-x86_64.o
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: error: ld returned 1 exit status
gmake: *** [shim] Error 1
This object file "crt0-efi-x86_64.o" is built with -fPIC, so I am not sure why the errors arise. Has anyone build shim 0.7 on Solaris and seen this issue? Any help is much appreciated.
Thanks,
Matt
Hey,
My current customer is using some network devices which only support UEFI boot mode (no classic bios). I've managed to configure PXE to boot RHEL7.2 using shim and grub2 but I get an error "kernel version is too old" when attempting to boot RHEL6.6/6.8.
Do you have any ideas about this issue? I'm going to try and compile shim/grub2 on RHEL6 and see if I can get it to work but I'm hitting a wall at the moment.
Cheers,
good day!
MokManager has option in menu: "Enroll hash from disk" [static void mok_hash_enroll(void)
].
but how to delete unnecessary hashes from mok ?
an malefactor can boot a old (bad, bugged) version of efi-file , that earlier was enrolled by MokManager's "Enroll hash from disk".
thanks in advance. and sorry for my bad english
There are a number of questions that Microsoft asks about UEFI signing submissions that I wasn't sure how best to answer. I figure these answers should be pretty generic for anyone trying to get a shim submission signed, so it'd be great if the answers could be publicly documented in this repo:
Do any of the products in this submission load or execute any other code prior to ExitBootServices()? If so, please explain how the code is loaded, authorized, and executed.
Do any of the products in this submission take any user input? If so, what input validation is performed?
Do any of the products in this submission take any programmatic input (files on disk, UEFI variables, etc.)? If so, what input validation is performed?
Do any of the products in this submission use OpenSSL? If so, which version?
Do any of the products in this submission consist of EfiByteCode? If so, what platforms are supported?
Just reporting, may want to test out Shim-15.
Prior known working shim is 0.9 on that mobo. I don't have access to it, remote system/user.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.