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 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

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.

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.

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

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".

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.

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

• context->PEHdr->Pe32Plus.OptionalHeader.ImageBase = (UINT64)data;
  -#else
• context->PEHdr->Pe32.OptionalHeader.ImageBase = (UINT32)data;
  -#endif
• if (context->PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {

•   #if **LP64**
  

•   context->PEHdr->Pe32Plus.OptionalHeader.ImageBase = (UINT64)data;
  

•   #else
  

•   perror(L"Loaded Image must be x86\n");
  

•   return EFI_UNSUPPORTED;
  

•   #endif
  

• }
• else if (context->PEHdr->Pe32.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC) {

•   #if **LP64**
  

•   perror(L"Loaded Image must be x64\n");
  

•   return EFI_UNSUPPORTED;
  

•   #else
  

•   context->PEHdr->Pe32.OptionalHeader.ImageBase = (UINT32)data;
  

•   #endif
  

• }
• else {

•   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

• 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);
  

  -#else
• 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);
  

  -#endif
• if (context->PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {

•   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);
  

• }
• else if (context->PEHdr->Pe32.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC) {

•   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);
  

• }
• else {

•   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;
  -#else
• SumOfBytesHashed = context->PEHdr->Pe32.OptionalHeader.SizeOfHeaders;
  -#endif
• if (context->PEHdr->Pe32Plus.OptionalHeader.Magic==EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC) {

•   SumOfBytesHashed = context->PEHdr->Pe32Plus.OptionalHeader.SizeOfHeaders;
  

• }
• else {

•   // 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

• 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
• 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);
  -#endif

• 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) {

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.

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!)

Testing Environment:

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

Steps to reproduce:

(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)

Expected behavior:

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.

Actual behaviour:

"Error: Failed to set variable: (2) Invalid Parameter"

Troubleshooting steps taken:

• tried different passwords, and was able to eliminate that being the cause.
• found relevant lines of code producing the error: lines 919-931 in https://github.com/rhinstaller/shim/blob/master/MokManager.c

  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;
}

• unable to find where uefi_call_wrapper() is defined

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)

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 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? 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.

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!

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.

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.

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

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.

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.

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

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?

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.

MokSBStateRT doesn't seem to be getting mirrored correctly (not showing up at all) with shim 15.

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.

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.

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.

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)

I'm trying to get UEFI netboot (PXE) working with secure boot. My plan is simply:

1. UEFI load Microsoft signed shim.efi from tftp
2. shim.efi load grub2 from tftp.

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.

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,

• Calvin

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

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.

I’d like to ask a question that how long dose shim take to get an audit ？Thanks very much ！

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)

1. mokutil --import mok.der
2. verify MOK is set to be enrolled via --list-new, and view new EFI vars with efivar -l
3. Reboot
4. MokManager is loaded, and I go through the enrollment menus. New MOK is present, and password is accepted. No errors are shown, and I select option to reboot.
5. Reboot to OS
6. 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.

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:

1. UEFI PXE ->
2. microsoft signed shim.ms.efi ->
3. vendor1 key signed shim.vendor1.efi with VENDOR_CERT_FILE=vendor2.der ->
4. vendor2 key signed ipxe.vendor2.efi ->
5. vendor2 key signed kernel vmlinuz.vendor2

The Trust chain looks like this:

1. shim.ms.efi boots because the MS keys are embedded in the UEFI firmware
2. shim.vendor1.efi boots because I added the vendor1.esl to the MokLis
3. ipxe.vendor2.efi boots because I added the vendor2.der inside shim.vendor1.efi
4. 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?

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.

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?

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:

1. Completely standalone, i.e. does not require the gnu-efi library. To access
   UEFI interfaces, it is using official Edk2/TianoCore headers.
2. Native UEFI PE/COFF (DLL) compilation using out-of-box clang/llvm
   (or, potentially, the mingw-gcc cross-compiler) instead of creating
   internally relocatable ELF objects with PE/COFF wrapper stubs (gnu-efi).
3. The Edk's FwImage tool (which I ported from Windows to Linux/POSIX)
   converts DLL to EFI.
4. Using smarter linking with llvm's PE/COFF lld-link to prune all unused
   functions/objects in the OpenSSL library.
5. Added own printf, string, memory, etc implementations to substitute
   functions previously imported from gnu-efi.
6. As the result, substantially reduced footprints of EFI files
   (e.g., 425Kb vs 1Mb for shimx64.efi compiled with -Os).
7. Fixed some bugs, removed a lot of copy&paste code from TianoCore
   (official TianoCore headers are now used anyway) and added other
   improvements to the code.

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

• Ruslan Nikolaev

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?

Hello.
I have problems with the EV embedded certificate.

1. Take Public Key in DER format im Windows.
2. Sign <stage2.loader.efi> in Windows (Digicert Utility or signtool.exe)
3. Compile shim.efi with PK 1. as embedded certificate in another Computer with Linux.
4. Verify file stage2.loader.efi with "sbverify". Tell "invalid algorithm type. Signature verification failed.", although on Windows PC with signtool.exe. "Verification pass."
5. Create a test flash drive. Install shim.efi -> grubx64.efi and stage2.loader.efi -> grub.efi.
6. When loading, shim tell "Verification failed: (15) Access Denied".

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

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

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?

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?

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

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

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:

/usr/local/gcc/bin/gcc -v

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)

there should be a config.h target

• it can either be satisfied by dropping a file in place or automatically generated from "git config" or the make command line
• for config options like DEFAULT_LOADER, EFIDIR, ENABLE_HTTPBOOT, etc

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.

(*) https://bugzilla.opensuse.org/show_bug.cgi?id=1092000

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

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 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

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?

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

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.

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.