Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple certificate handling improvements #644

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

rosslagerwall
Copy link

A couple of improvements for performing verification with multiple certificates.

@vathpela
Copy link
Contributor

vathpela commented May 8, 2024

Is there existing usage of these packed certificates? It would seem like the obvious way to do this is multiple EFI_SIGNATURE_LIST entries each with an EFI_CERT_TYPE_X509_GUID entry. If something else is already supporting the packed version, though, I don't have a big problem with it.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
@rosslagerwall rosslagerwall force-pushed the private/rossla/cert branch from fbf536c to 0885b25 Compare May 9, 2024 09:23
@rosslagerwall
Copy link
Author

Is there existing usage of these packed certificates? It would seem like the obvious way to do this is multiple EFI_SIGNATURE_LIST entries each with an EFI_CERT_TYPE_X509_GUID entry. If something else is already supporting the packed version, though, I don't have a big problem with it.

Nothing that I am aware of. On reflection, that change is unnecessary so I've dropped the commit. The remaining commits fix a leak and allow having multiple EFI_SIGNATURE_LIST entries each with an EFI_CERT_TYPE_X509_GUID entry.

Thanks

@rosslagerwall rosslagerwall force-pushed the private/rossla/cert branch from 0885b25 to 3e05585 Compare May 9, 2024 09:28
For multiple reasons, it may be useful for different keys to be used to
sign different parts of the boot chain (e.g. a different key for GRUB
and the Linux kernel). Allow this by loading concatenated
EFI_SIGNATURE_LISTs from shim_certificate.efi rather than only the
first.

At the same time, be a bit more robust by checking for allocation
failures and overflows due to invalid data in the binary.
Use the smaller of VirtualSize and SizeOfRawData since the latter is
rounded up to the section alignment and therefore may contain
non-certificate data.

Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants