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

Make EFI variable copying fatal only on secureboot enabled systems #157

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@puiterwijk

puiterwijk commented Dec 6, 2018

I have come across systems that are unwilling to reserve enough memory for
a MokListRT big enough for big certificates.
This seems to be the case with firmware implementations that do not support
secureboot, which is probably the reason they went with much lower variable
storage.

This patch set makes sure we can still boot on those systems, by only
making the copy action fatal if the system has secure boot enabled, or if
the error was anything other than EFI_INVALID_PARAMETER.

Signed-off-by: Patrick Uiterwijk patrick@puiterwijk.org

@arrfab

This comment has been minimized.

arrfab commented Dec 6, 2018

FWIW, it affects some CentOS Users and we consolidated all feedback in the following bug report :
https://bugs.centos.org/view.php?id=15522
Some people confirm that the .patch in this commit permit affected uefi nodes to boot fine (not considered critical error anymore)

@lcp

This comment has been minimized.

Contributor

lcp commented Dec 7, 2018

If it's the generation of MokListRT causing the failure, it'd be better to change the condition check right after import_mok_state(). The code after the "die" label means the program must be terminated after showing the error messages.

@arrfab arrfab referenced this pull request Dec 7, 2018

Open

shim-15 for CentOS 7.6.1810 - version 2 #45

7 of 7 tasks complete
Make EFI variable copying fatal only on secureboot enabled systems
I have come across systems that are unwilling to reserve enough memory for
a MokListRT big enough for big certificates.
This seems to be the case with firmware implementations that do not support
secureboot, which is probably the reason they went with much lower variable
storage.

This patch set makes sure we can still boot on those systems, by only
making the copy action fatal if the system has secure boot enabled, or if
the error was anything other than EFI_INVALID_PARAMETER.

Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>

@puiterwijk puiterwijk force-pushed the puiterwijk:non-sb-non-fatal branch from 9a2dd0a to f710291 Dec 8, 2018

@puiterwijk

This comment has been minimized.

puiterwijk commented Dec 8, 2018

@lcp thanks for that feedback, I ended up adding an additional if clause which only triggers in this specific case.

@lcp

This comment has been minimized.

Contributor

lcp commented Dec 11, 2018

Looks good to me :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment