Disable exporting vendor-dbx to MokListXRT - #514
Conversation
frozencemetery
left a comment
There was a problem hiding this comment.
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.
|
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>
|
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: A README.compile will be added soon. |
|
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. |
|
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. |
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