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

Relax the check for import_mok_state() #372

Merged
merged 1 commit into from
Jun 23, 2021

Conversation

lcp
Copy link
Collaborator

@lcp lcp commented May 19, 2021

An openSUSE user reported(*) that shim 15.4 failed to boot the system
with the following message:

"Could not create MokListXRT: Out of Resources"

In the beginning, I thought it's caused by the growing size of
vendor-dbx. However, we found the following messages after set
SHIM_VERBOSE:

max_var_sz:8000 remaining_sz:85EC max_storage_sz:9000
SetVariable(“MokListXRT”, ... varsz=0x1404) = Out of Resources

Even though the firmware claimed the remaining storage size is 0x85EC
and the maximum variable size is 0x8000, it still rejected MokListXRT
with size 0x1404. It seems that the return values from QueryVariableInfo()
are not reliable. Since this firmware didn't really support Secure Boot,
the variable mirroring is not so critical, so we can just accept the
failure of import_mok_state() and continue boot.

(*) https://bugzilla.suse.com/show_bug.cgi?id=1185261

Signed-off-by: Gary Lin glin@suse.com

An openSUSE user reported(*) that shim 15.4 failed to boot the system
with the following message:

  "Could not create MokListXRT: Out of Resources"

In the beginning, I thought it's caused by the growing size of
vendor-dbx. However, we found the following messages after set
SHIM_VERBOSE:

  max_var_sz:8000 remaining_sz:85EC max_storage_sz:9000
  SetVariable(“MokListXRT”, ... varsz=0x1404) = Out of Resources

Even though the firmware claimed the remaining storage size is 0x85EC
and the maximum variable size is 0x8000, it still rejected MokListXRT
with size 0x1404. It seems that the return values from QueryVariableInfo()
are not reliable. Since this firmware didn't really support Secure Boot,
the variable mirroring is not so critical, so we can just accept the
failure of import_mok_state() and continue boot.

(*) https://bugzilla.suse.com/show_bug.cgi?id=1185261

Signed-off-by: Gary Lin <glin@suse.com>
Copy link
Collaborator

@julian-klode julian-klode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think this is a reasonable change, and IIRC, we saw the same thing in Ubuntu too, though we are working around it by stopping to mirror our large dbx - but this probably makes sense to pick as well.

@steve-mcintyre
Copy link
Collaborator

Definitely looks good to me too - we've been bitten by the same problem in Debian:

@steve-mcintyre steve-mcintyre merged commit 9f973e4 into rhboot:main Jun 23, 2021
pmhahn pushed a commit to univention/shim that referenced this pull request Sep 20, 2021
dbnicholson pushed a commit to endlessm/shim that referenced this pull request Apr 11, 2023
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.

None yet

4 participants