[personal profile] mjg59
Shim has been hugely successful, to the point of being used by the majority of significant Linux distributions and many other third party products (even, apparently, Solaris). The aim was to ensure that it would remain possible to install free operating systems on UEFI Secure Boot platforms while still allowing machine owners to replace their bootloaders and kernels, and it's achieved this goal.

However, a legitimate criticism has been that there's very little transparency in Microsoft's signing process. Some people have waited for significant periods of time before being receiving a response. A large part of this is simply that demand has been greater than expected, and Microsoft aren't in the best position to review code that they didn't write in the first place.

To that end, we're adopting a new model. A mailing list has been created at shim-review@lists.freedesktop.org, and members of this list will review submissions and provide a recommendation to Microsoft on whether these should be signed or not. The current set of expectations around binaries to be signed documented here and the current process here - it is expected that this will evolve slightly as we get used to the process, and we'll provide a more formal set of documentation once things have settled down.

This is a new initiative and one that will probably take a little while to get working smoothly, but we hope it'll make it much easier to get signed releases of Shim out without compromising security in the process.

ARM build restriction

Date: 2017-03-22 04:53 am (UTC)
From: (Anonymous)
What's the story behind the ARM build restriction?

Re: ARM build restriction

Date: 2017-03-22 01:13 pm (UTC)
From: [identity profile] pjones.id.fedoraproject.org
https://msdn.microsoft.com/windows/hardware/commercialize/design/compatibility/systems#systemfundamentalsfirmwarecsuefisecurebootconnectedstandby ("System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby" if that link is weird for you like it is for me) #6 and #13 are problematic for shipping signed GPL programs.

Date: 2017-03-23 07:35 pm (UTC)
From: [identity profile] bgilbert.id.fedoraproject.org
Does this process replace the current mechanism and requirements for submitting shim binaries to be signed (e.g. https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/03/microsoft-uefi-ca-signing-policy-updates), or is it intended to supplement them?

vague requirements

Date: 2017-03-24 08:09 pm (UTC)
From: (Anonymous)
There are at least a couple occurrences of vaguely defined requirements in the document. For example, "There should also be well-signed PGP keys to use when contacting these people in the event of a situation." How are you defining "should"? Will requests be rejected if there aren't keys? How are you defining "well-signed"?

I understand that each case is ultimately going to be handled individually, but ultimately it'll help applicants meet the expected quality bar if the bar is well defined.

UEFI TPM2

Date: 2017-03-29 04:28 am (UTC)
From: (Anonymous)
Hi Matthew,

I successfully combined your GRU2 TPM bootloader with Tiancore's fTPM-UEFI and IBM's user-space TPM suite. Now I'm in the last step of porting your TPM function calls into Linux kernel's exec() system call in order to trace all software launches and extends to the PCR. However, I've been working for 40 hours, yet couldn't successfully port your "grub_tpm_measure()" function inside exec().

The major problem is, in the kernel space, the entries of elf_system_table structure are invalid. Linux kernel initializes the elf system table structure within "efi.c" file's efi_systab_init() function. To use TPM like your GRUB2 does, I need to access efi->system_table->boottime->locate_handle() function pointer. But boottime pointer is an invalid memory address, so if I try to access locate_handle(), I get kernel panick.

Another issue is, your efi_boot_services_t structure's 'open_protocol' is a function pointer, whereas the Linux version is void* variable.

Lastly, in your GRUB2 code you said "grub_efi_image_handle" and "efi_system_table" will be filled out by the system upon booting, and I see that Linux kernel fills out efi_system_table in efi_systab_init() function in efi.c file. However, I can't find anywhere the kernel defines and fills in "grub_efi_image_handle",and you use this variable for the TPM's PCR extension.

Am I on a completely wrong track in using the EFI structure inside the kernel? Is that why my EFI_entries are invalid? Could you please give me tips just for once for porting your tpm_measure into the kernel? I don't know where to turn anymore..

Shim Review Progress

Date: 2017-09-20 08:18 am (UTC)
From: (Anonymous)
Hi Matthew

I (and others) on the shim review list are not getting any progress on our submitted requests - even after months of waiting, do you know to whom we should put in a good word to move things forward?

I'm the CTO of FileWave, and can be contacted on Skype and john-c-clayton (remove the dashes).

Thanks

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags