Skip to content

mok: Add a building option to avoid the vendor_dbx being appended to … - #779

Open
joeyli wants to merge 1 commit into
rhboot:mainfrom
joeyli:16.1-DISABLE_APPEND_V_DBX_TO_MOKX
Open

mok: Add a building option to avoid the vendor_dbx being appended to …#779
joeyli wants to merge 1 commit into
rhboot:mainfrom
joeyli:16.1-DISABLE_APPEND_V_DBX_TO_MOKX

Conversation

@joeyli

@joeyli joeyli commented Oct 17, 2025

Copy link
Copy Markdown
Contributor

…MokListRT

The new building option DISABLE_APPEND_V_DBX_TO_MOKX avoids appending the vendor_dbx to MokListRT. Instead, the vendor_dbx will be exposed through the mok config table space.

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. If your shim and kernel don't rely on MokListXRT to block anything, you can use this building option to expose vendor_dbx through the mok config table instead of appending it to MokListRT.

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

…MokListRT

The new building option DISABLE_APPEND_V_DBX_TO_MOKX avoids appending
the vendor_dbx to MokListRT. Instead, the vendor_dbx will be exposed
through the mok config table space.

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. If
your shim and kernel don't rely on MokListXRT to block anything, you
can use this building option to expose vendor_dbx through the mok
config table instead of appending it to MokListRT.

Link: https://bugzilla.suse.com/show_bug.cgi?id=1185261 [1]
Link: rhboot#369 (comment) [2]
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
@vathpela
vathpela force-pushed the 16.1-DISABLE_APPEND_V_DBX_TO_MOKX branch from e139eb7 to c998f25 Compare July 23, 2026 18:16
@vathpela

Copy link
Copy Markdown
Member

I don't think I have a problem with any of this, but it does lead me to some questions about the direction we should be going:

  1. I wonder if it's not worth always having VendorDBX
  2. If we're doing that, why do we merge at all, why not separate everything? In the past we've merged them so that userland tools could just look at one thing, but maybe that's not the best way forward.
  3. Clearly we should be moving away from creating the EFI variables at all...

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