From: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
To: grub-devel@gnu.org
Cc: dja@axtens.net, jan.setjeeilers@oracle.com,
julian.klode@canonical.com, mate.kukri@canonical.com,
pjones@redhat.com, msuchanek@suse.com, mlewando@redhat.com,
stefanb@linux.ibm.com, avnish@linux.ibm.com, nayna@linux.ibm.com,
ssrish@linux.ibm.com, Sudhakar Kuppusamy <sudhakar@linux.ibm.com>,
sridharm@linux.ibm.com, Daniel Kiper <daniel.kiper@oracle.com>
Subject: [PATCH v18 20/20] docs/grub: Document appended signature
Date: Mon, 6 Oct 2025 12:55:05 +0530 [thread overview]
Message-ID: <20251006072508.19088-21-sudhakar@linux.ibm.com> (raw)
In-Reply-To: <20251006072508.19088-1-sudhakar@linux.ibm.com>
This explains how appended signatures can be used to form part of
a secure boot chain, and documents the commands and variables
introduced.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
---
docs/grub.texi | 325 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 325 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index c462c68e7..7cd5dee06 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3281,8 +3281,10 @@ GRUB. Others may be used freely in GRUB configuration files.
These variables have special meaning to GRUB.
@menu
+* appendedsig_key_mgmt::
* biosnum::
* blsuki_save_default::
+* check_appended_signatures::
* check_signatures::
* chosen::
* cmdpath::
@@ -3333,6 +3335,19 @@ These variables have special meaning to GRUB.
@end menu
+@node appendedsig_key_mgmt
+@subsection appendedsig_key_mgmt
+
+This variable controls whether GRUB enforces appended signature validation
+using either @code{static} or @code{dynamic} key management. It is automatically
+set by GRUB to either @code{static} or @code{dynamic} based on the
+@strong{'ibm,secure-boot'} device tree property and Platform KeyStore (PKS).
+Also, it can be explicitly set to either @code{static} or @code{dynamic} by
+setting the @code{appendedsig_key_mgmt} variable from the GRUB console
+when the GRUB is not locked down.
+
+@xref{Using appended signatures} for more information.
+
@node biosnum
@subsection biosnum
@@ -3353,6 +3368,17 @@ If this variable is set, menu entries generated from BLS config files
(@pxref{blscfg}) or UKI files (@pxref{uki}) will be set as the default boot
entry when selected.
+@node check_appended_signatures
+@subsection check_appended_signatures
+
+This variable controls whether GRUB enforces appended signature validation on
+loaded kernel and GRUB module files. It is automatically set by GRUB
+to either @code{no} or @code{yes} based on the @strong{'ibm,secure-boot'} device
+tree property. Also, it can be explicitly set to either @code{no} or @code{yes} by
+setting the @code{check_appended_signatures} variable from the GRUB console
+when the GRUB is not locked down.
+
+@xref{Using appended signatures} for more information.
@node check_signatures
@subsection check_signatures
@@ -6546,6 +6572,13 @@ you forget a command, you can run the command @command{help}
@menu
* [:: Check file types and compare values
* acpi:: Load ACPI tables
+* append_add_db_cert:: Add trusted certificate to the db list
+* append_add_db_hash:: Add trusted certificate/binary hash to the db list
+* append_add_dbx_cert:: Add distrusted certificate to the dbx list
+* append_add_dbx_hash:: Add distrusted certificate/binary hash to the dbx list
+* append_list_db:: List all trusted certificates from the db list
+* append_list_dbx:: List all distrusted certificates and binary/certificate hashes from the dbx list
+* append_verify:: Verify appended digital signature using db and dbx lists
* authenticate:: Check whether user is in user list
* background_color:: Set background color for active terminal
* background_image:: Load background image for active terminal
@@ -6669,6 +6702,140 @@ Note: The command is not allowed when lockdown is enforced (@pxref{Lockdown}).
unsigned code.
@end deffn
+@node append_add_db_cert
+@subsection append_add_db_cert
+
+@deffn Command append_add_db_cert <X509_certificate>
+Read an X.509 certificate from the file @var{X509_certificate}
+and add it to GRUB's internal db list of trusted certificates.
+These certificates are used to validate appended signatures when the
+environment variable @code{check_appended_signatures} (@pxref{check_appended_signatures})
+is set to @code{yes} or the @command{append_verify} (@pxref{append_verify})
+command is executed from the GRUB console.
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_add_db_hash
+@subsection append_add_db_hash
+
+@deffn Command append_add_db_hash <hash_file>
+Read a binary hash from the file @var{hash_file}
+and add it to GRUB's internal db list of trusted binary hashes. These
+hashes are used to validate the Linux kernel/GRUB module binary hashes when the
+environment variable @code{check_appended_signatures}
+(@pxref{check_appended_signatures}) is set to @code{yes} or the
+@command{append_verify} (@pxref{append_verify}) command is executed
+from the GRUB console.
+
+Here is an example for how to generate a SHA-256 hash for a file. The hash
+will be in binary format:
+
+@example
+
+# The vmlinux (kernel image) file is your binary file, and
+# it should be unsigned.
+#
+# Generate the binary_hash.bin file from the vmlinux file
+# using OpenSSL command
+
+openssl dgst -binary -sha256 -out binary_hash.bin vmlinux
+
+@end example
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_add_dbx_cert
+@subsection append_add_dbx_cert
+
+@deffn Command append_add_dbx_cert <X509_certificate>
+Read an X.509 certificate from the file @var{X509_certificate}
+and add it to GRUB's internal dbx list of distrusted certificates.
+These certificates are used to ensure that the distrusted certificates
+are rejected during appended signatures validation when the environment
+variable @code{check_appended_signatures} is set to @code{yes}
+(@pxref{check_appended_signatures}) or the @command{append_verify}
+(@pxref{append_verify}) command is executed from the GRUB console.
+Also, these certificates are used to prevent distrusted certificates from
+being added to the db list later on.
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_add_dbx_hash
+@subsection append_add_dbx_hash
+
+@deffn Command append_add_dbx_hash [@option{-b}|@option{-c}] <hash_file>
+Read a binary/certificate hash from the file @var{hash_file}
+and add it to GRUB's internal dbx list of distrusted binary/certificate hashes.
+When the environment variable @code{check_appended_signatures} (@pxref{check_appended_signatures})
+is set to @code{yes} or the @command{append_verify} (@pxref{append_verify}) command
+is executed from the GRUB console, then matching distrusted binary hashes or the signature
+validation with distrusted certificates may lead to the rejection of the Linux kernel or GRUB modules.
+Also, these hashes are used to prevent distrusted certificates and binary hashes from being
+added to the db list later on.
+
+The @option{-b} (@option{--binary-hash}) can be used to specify a binary hash file and
+@option{-c} (@option{--cert-hash}) can be used to specify a certificate hash file.
+
+Here is an example for how to generate a SHA-256 hash for a binary and a
+certificate file. The hash will be in binary format:
+
+@example
+
+# The vmlinux (kernel image) file is your binary file, and
+# it should be unsigned. The kernel.der is your certificate file.
+#
+# Generate the cert_hash.bin file from the kernel.der file
+
+openssl dgst -binary -sha256 -out cert_hash.bin kernel.der
+
+# Generate the binary_hash.bin file from the vmlinux file
+
+openssl dgst -binary -sha256 -out binary_hash.bin vmlinux
+
+@end example
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_list_db
+@subsection append_list_db
+
+@deffn Command append_list_db
+List all X.509 certificates and binary hashes trusted by GRUB for validating
+appended signatures. The output is a numbered list of certificates and binary hashes,
+showing the certificate's version, serial number, issuer, subject,
+public key algorithm, RSA public key size, and certificate fingerprint.
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_list_dbx
+@subsection append_list_dbx
+
+@deffn Command append_list_dbx
+List all the distrusted X.509 certificates and binary/certificate hashes.
+The output is a numbered list of certificates and binary/certificate hashes,
+showing the certificate's version, serial number, issuer, subject,
+public key algorithm, RSA public key size, and certificate fingerprint.
+
+@xref{Using appended signatures} for more information.
+@end deffn
+
+@node append_verify
+@subsection append_verify
+
+@deffn Command append_verify <signed_file>
+Verifies an appended signature on @var{signed_file} against the trusted X.509 certificates
+and hashes known to GRUB (@pxref{append_list_db},@pxref{append_list_dbx}, @pxref{append_add_db_cert},
+@pxref{append_add_db_hash}, @pxref{append_add_dbx_hash} and @pxref{append_add_dbx_cert}).
+Exit code @code{$?} is set to 0 if the signature validates successfully.
+If validation fails, it is set to a non-zero value.
+
+@xref{Using appended signatures} for more information.
+@end deffn
@node authenticate
@subsection authenticate
@@ -7507,6 +7674,13 @@ configurations, but to allow the user to select from among multiple
configurations, and to enable ``one-shot'' boot attempts and
``savedefault'' behavior. @xref{Using GPG-style digital signatures}, for more
information.
+
+If the environment variable @code{check_appended_signatures} value is set to
+@code{yes} and GRUB is in lockeddown mode, the user is not allowed to set
+@code{check_appended_signatures} to @code{no} and @code{appendedsig_key_mgmt}
+to @code{static} or @code{dynamic} either directly using @command{load_env}
+command or via environment block file. @xref{Using appended signatures}, for
+more information.
@end deffn
@@ -8902,11 +9076,13 @@ environment variables and commands are listed in the same order.
@menu
* Authentication and authorisation:: Users and access control
* Using GPG-style digital signatures:: Booting digitally signed code
+* Using appended signatures:: An alternative approach to booting digitally signed code
* UEFI secure boot and shim:: Booting digitally signed PE files
* Secure Boot Advanced Targeting:: Embedded information for generation number based revocation
* Measured Boot:: Measuring boot components
* Lockdown:: Lockdown when booting on a secure setup
* TPM2 key protector:: Managing disk key with TPM2 key protector
+* Signing certificate and hash files:: Certificate and hash file signing
* Signing GRUB itself:: Ensuring the integrity of the GRUB core image
@end menu
@@ -9067,6 +9243,127 @@ or BIOS) configuration to cause the machine to boot from a different
(attacker-controlled) device. GRUB is at best only one link in a
secure boot chain.
+@node Using appended signatures
+@section Using appended signatures in GRUB
+
+GRUB supports verifying Linux-style 'appended signatures' for Linux on Power LPAR
+secure boot. Appended signatures are PKCS#7 messages containing a signature over the
+contents of a file, plus some metadata, appended to the end of a file. A file
+with an appended signature ends with the magic string:
+
+@example
+~Module signature appended~\n
+@end example
+
+where @code{\n} represents the line feed character, @code{0x0a}.
+
+Linux on Power LPAR secure boot is controlled by @strong{'ibm,secure-boot'}
+device tree property and if this property is set to @code{2} (@samp{enforce}),
+GRUB enters lockdown mode. There are three secure boot modes. They are
+
+@itemize
+@item @samp{0 - disabled}: Secure boot is disabled. This is the default.
+@item @samp{1 - audit}: Enforce signature verification by setting
+ @code{check_appended_signatures} (@pxref{check_appended_signatures}) to
+ @code{yes} and do not enter lockdown mode. Signature verification
+ is performed and if signature verification fails, display the errors and
+ allow the boot to continue.
+@item @samp{2 - enforce}: Enter lockdown mode and enforce signature verification by setting
+ @code{check_appended_signatures} (@pxref{check_appended_signatures}) to @code{yes}.
+@end itemize
+
+Note that Linux on Power LPAR only supports @samp{0 - disabled} and @samp{2 - enforce},
+and @samp{1 - audit} is considered as secure boot being disabled.
+
+Enforcement of signature verification is controlled by the environment variable
+@code{check_appended_signatures} (@pxref{check_appended_signatures}).
+
+@itemize
+@item @samp{no}: No verification is performed. This is the default.
+@item @samp{yes}: Signature verification is performed and if signature verification fails,
+ display the errors and stop the boot. Signature verification cannot be disabled by setting
+ the @code{check_appended_signatures} variable back to @samp{no}.
+@end itemize
+
+To enable appended signature verification, load the appendedsig module and an
+X.509 certificate for verification. It is recommended to build the appendedsig module
+into the core GRUB image.
+
+Key management is controlled by the environment variable @code{appendedsig_key_mgmt}
+(@pxref{appendedsig_key_mgmt}).
+
+@itemize
+@item @samp{static}: Enforce static key management signature verification. This is the default.
+ When GRUB is in lockdown mode, then the user cannot change the value of the
+ @code{appendedsig_key_mgmt}.
+@item @samp{dynamic}: Enforce dynamic key management signature verification. When GRUB is in
+ lockdown mode, then the user cannot change the value of the @code{appendedsig_key_mgmt}.
+@end itemize
+
+In static key management mode, certificates will be built into the core image using
+the @code{--x509} parameter to @command{grub-mkimage}. The list of trusted certificates
+available at boot time can be shown using @command{append_list_db} (@pxref{append_list_db}).
+Distrusted certificates can be explicitly removed from the db using @command{append_add_dbx_cert}
+(@pxref{append_add_dbx_cert}). Also, trusted certificates can be explicitly added to the db using
+@command{append_add_db_cert} (@pxref{append_add_db_cert}).
+
+In dynamic key management mode, db and dbx are read from the Platform KeyStore (PKS). If
+db does not exist in PKS, static keys (built-in keys) are used as the default keys.
+The list of trusted certificates and binary hashes available at boot time can be shown using
+@command{append_list_db} (@pxref{append_list_db}) and the list of distrusted certificates and
+binary/certificate hashes available at boot time can be shown using @command{append_list_dbx}
+(@pxref{append_list_dbx}). The trusted certificates and binary hashes can be explicitly added
+to the db using @command{append_add_db_cert} (@pxref{append_add_db_cert}) and
+@command{append_add_db_hash} (@pxref{append_add_db_hash}). Distrusted certificates can be explicitly
+added to the dbx using @command{append_add_dbx_cert} (@pxref{append_add_dbx_cert}) and distrusted
+certificate/binary hashes can be explicitly added to the dbx using @command{append_add_dbx_hash}
+(@pxref{append_add_dbx_hash}).
+
+A file can be explicitly verified using @command{append_verify} (@pxref{append_verify}).
+
+Note that when the environment variable @code{check_appended_signatures} is set to @code{yes},
+the @command{append_add_db_cert} and @command{append_add_dbx_cert} commands only accept
+the file @samp{@var{X509_certificate}} that is signed with an appended signature
+(@pxref{Signing certificate and hash files}), and the @command{append_add_db_hash} and
+@command{append_add_dbx_hash} commands only accept the file @samp{@var{hash_file}} that is
+signed with an appended signature (@pxref{Signing certificate and hash files}).
+The signature is verified by the appendedsig module.
+When the environment variable @code{check_appended_signatures} is set to @code{no},
+these commands accept files without an appended signature.
+
+Also, note that @samp{@var{X509_certificate}} should be in DER-format and @samp{@var{hash_file}}
+should be in binary format. Only SHA-256, SHA-384, or SHA-512 hashes of binary/certificate are allowed.
+Certificates/hashes of certificates/binaries added through @command{append_add_db_cert},
+@command{append_add_dbx_cert}, @command{append_add_db_hash}, and @command{append_add_dbx_hash}
+will not be persisted across boots.
+
+Only signatures created using SHA-256 or SHA-512 hash algorithm along with RSA keys of size 2048,
+3072, or 4096 bits are supported.
+
+A file can be signed with the @command{sign-file} utility supplied with the
+Linux kernel source. For example, if you have @code{signing.key} as the private
+key and @code{certificate.der} as the X.509 certificate containing the public key:
+
+@example
+sign-file SHA256 signing.key certificate.der vmlinux vmlinux.signed
+@end example
+
+Once signature verification is turned on, the following file types must carry
+appended signatures:
+
+@enumerate
+@item Linux kernels
+@item GRUB modules, except those built in to the core image
+@item Any new certificate or binary hash files to be trusted
+@item Any new certificate/binary hash files to be distrusted
+@end enumerate
+
+When GRUB is in lockdown mode (when secure boot mode is set to @code{enforce}),
+signature verification cannot be @strong{disabled} by setting the
+@code{check_appended_signatures} (@pxref{check_appended_signatures}) variable
+to @code{no} or using the @command{load_env} (@pxref{load_env}) command from
+the GRUB console.
+
@node UEFI secure boot and shim
@section UEFI secure boot and shim support
@@ -9596,6 +9893,34 @@ which increases the risk of password leakage during the process. Moreover, the
superuser list must be well maintained, and the password used cannot be
synchronized with LUKS key rotation.
+@node Signing certificate and hash files
+@section Signing certificate and hash files
+X.509 certificate (public key) files and hash files (binary/certificate hash files)
+can be signed with a Linux kernel module-style appended signature.
+
+The signer.key is a private key used for signing and signer.der is the corresponding
+public key (certificate) used for appended signature verification. Note that the
+signer.der (certificate) should exist in the db (@pxref{Using appended signatures}).
+
+@itemize
+@item Signing the X.509 certificate file using @file{sign-file}.
+The kernel.der is an X.509 certificate file.
+@example
+
+sign-file SHA256 signer.key signer.der kernel.der \
+ kernel.der.signed
+
+@end example
+@item Signing the hash file using @file{sign-file}.
+The binary_hash.bin is a binary hash file.
+@example
+
+sign-file SHA256 signer.key signer.der binary_hash.bin \
+ binary_hash.signed
+
+@end example
+@end itemize
+
@node Signing GRUB itself
@section Signing GRUB itself
To ensure a complete secure-boot chain, there must be a way for the code that
--
2.50.1 (Apple Git-155)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
prev parent reply other threads:[~2025-10-06 7:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 7:24 [PATCH v18 00/20] Appended Signature Secure Boot Support for PowerPC Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 01/20] powerpc-ieee1275: Add support for signing GRUB with an appended signature Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 02/20] crypto: Move storage for grub_crypto_pk_* to crypto.c Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 03/20] pgp: Rename OBJ_TYPE_PUBKEY to OBJ_TYPE_GPG_PUBKEY Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 04/20] grub-install: Support embedding x509 certificates Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 05/20] appended signatures: Import GNUTLS's ASN.1 description files Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 06/20] appended signatures: Parse ASN1 node Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 07/20] appended signatures: Parse PKCS#7 signed data Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 08/20] appended signatures: Parse X.509 certificates Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 09/20] powerpc_ieee1275: Enter lockdown based on /ibm, secure-boot Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 10/20] appended signatures: Support verifying appended signatures Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 11/20] powerpc_ieee1275: Read the db and dbx secure boot variables Sudhakar Kuppusamy
2026-02-24 18:47 ` John Paul Adrian Glaubitz
2026-02-27 13:52 ` Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 12/20] appended signatures: Introducing key management environment variable Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 13/20] appended signatures: Create db and dbx lists Sudhakar Kuppusamy
2025-10-06 7:24 ` [PATCH v18 14/20] appended signatures: Using db and dbx lists for signature verification Sudhakar Kuppusamy
2025-10-06 7:25 ` [PATCH v18 15/20] appended signatures: GRUB commands to manage the certificates Sudhakar Kuppusamy
2025-10-06 7:25 ` [PATCH v18 16/20] appended signatures: GRUB commands to manage the hashes Sudhakar Kuppusamy
2025-10-06 7:25 ` [PATCH v18 17/20] appended signatures: Verification tests Sudhakar Kuppusamy
2025-10-06 7:25 ` [PATCH v18 18/20] docs/grub: Document signing GRUB under UEFI Sudhakar Kuppusamy
2025-10-06 7:25 ` [PATCH v18 19/20] docs/grub: Document signing GRUB with an appended signature Sudhakar Kuppusamy
2025-10-06 7:25 ` Sudhakar Kuppusamy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251006072508.19088-21-sudhakar@linux.ibm.com \
--to=sudhakar@linux.ibm.com \
--cc=avnish@linux.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=dja@axtens.net \
--cc=grub-devel@gnu.org \
--cc=jan.setjeeilers@oracle.com \
--cc=julian.klode@canonical.com \
--cc=mate.kukri@canonical.com \
--cc=mlewando@redhat.com \
--cc=msuchanek@suse.com \
--cc=nayna@linux.ibm.com \
--cc=pjones@redhat.com \
--cc=sridharm@linux.ibm.com \
--cc=ssrish@linux.ibm.com \
--cc=stefanb@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.