Skip to content

Disable exporting vendor-dbx to MokListXRT - #514

Closed
dennis-tseng99 wants to merge 1 commit into
rhboot:mainfrom
dennis-tseng99:disable-export-dbx
Closed

Disable exporting vendor-dbx to MokListXRT#514
dennis-tseng99 wants to merge 1 commit into
rhboot:mainfrom
dennis-tseng99:disable-export-dbx

Conversation

@dennis-tseng99

Copy link
Copy Markdown
Contributor

As the vendor-dbx grows, it caused some problems when writing such a large variable. Some firmwares lie the avaiable space(*1) , and some even crash(*2) for no good reason after the writing of MokListXRT. Both shim and kernel don't rely on MokListXRT to block anything, so we just stop exporting vendor-dbx to MokListXRT to avoid the potential hassles.

(*1) https://bugzilla.suse.com/show_bug.cgi?id=1185261
(*2) #369 (comment)

Signed-off-by: Gary Lin glin@suse.com
Signed-off-by: Dennis Tseng dennis.tseng@suse.com

@frozencemetery frozencemetery left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This PR introduces a new configuration option. I dislike this in general: where possible, we should figure out whether "defined" or "undefined" is correct, and not have it configurable. (In this specific case, it's worse because the define is secret - there's no documentation or mention of it other than reading the source.)

I think there's a conversation to be had here on whether handling the write error or disabling exporting it altogether are correct and others beyond me will I hope weigh in on that.

@dennis-tseng99

Copy link
Copy Markdown
Contributor Author

Thanks for your comments indeed. Yes, I should explain more details. The reason I set a configuration option is actually I'm not sure whether other vendors with their machines will have the same issue or not. If yes, I will remove this option and the line 122 & 123 directly.

As the vendor-dbx grows, it caused some problems when writing such
a large variable. Some firmwares lie the avaiable space(*1) , and
some even crash(*2) for no good reason after the writing of
MokListXRT. Both shim and kernel don't rely on MokListXRT to block
anything, so we just stop exporting vendor-dbx to MokListXRT to
avoid the potential hassles. A configuration option is added in
mok.c to stop exporting. For those vendors who do not have such
issue will feel nothing changed. On the other hand, if vendors
want to stop exporting, then the DISABLE_EXPORT_DBX must be defined
in Makefile and shim.spec command-line respectively. For example:
In Makefile:
CFLAGS += -DDISABLE_EXPORT_DBX
In shim.spec:
make RELEASE=0 ... DISABLE_EXPORT_DBX=1 ... shim.efi

(*1) https://bugzilla.suse.com/show_bug.cgi?id=1185261
(*2) #369 (comment)

Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Dennis Tseng <dennis.tseng@suse.com>
@dennis-tseng99

Copy link
Copy Markdown
Contributor Author

A configuration option is added in mok.c to stop exporting. For those vendors who do not have such issue will feel nothing changed. On the other hand, if vendors want to stop exporting, then the DISABLE_EXPORT_DBX must be defined in Makefile and shim.spec command-line respectively. For example:
In Makefile:
CFLAGS += -DDISABLE_EXPORT_DBX
In shim.spec:
make RELEASE=0 ... DISABLE_EXPORT_DBX=1 ... shim.efi

A README.compile will be added soon.

@frozencemetery
frozencemetery marked this pull request as draft October 10, 2022 16:20
@julian-klode

Copy link
Copy Markdown
Collaborator

Basically anyone with a larger vendor dbx needs this. We've been shipping this without a config option in Ubuntu for a while and I think we gotta continue despite us switching from 20 KB of hashes to like 9KB of certs - it's still to big.

The Linux kernel can revoke via certificate hashes, which would significantly reduce the size requirement, but I'm not sure how one would represent that.

@vathpela

Copy link
Copy Markdown
Member

I don't really like the implementation here - I'd rather see a mok_state_variable flag to say to mirror it using config table space but not variable space, rather than simply not adding the data we have.

@joeyli

joeyli commented Oct 17, 2025

Copy link
Copy Markdown
Contributor

I don't really like the implementation here - I'd rather see a mok_state_variable flag to say to mirror it using config table space but not variable space, rather than simply not adding the data we have.

Thanks for Peter's suggestion. I am producing a new patch that it will expose vendor_dbx to /sys/firmware/efi/mok-variables/VendorDBX. I will create a new submitreq.

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.

5 participants