Announcing the Shim review process
Mar. 21st, 2017 01:29 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Shim 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
ARM build restriction
Date: 2017-03-22 04:53 am (UTC)Re: ARM build restriction
Date: 2017-03-22 01:13 pm (UTC)no subject
Date: 2017-03-23 07:35 pm (UTC)vague requirements
Date: 2017-03-24 08:09 pm (UTC)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)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)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
No progress with shim review process?
Date: 2019-09-02 02:18 pm (UTC)