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 v13 20/20] docs/grub: Document appended signature
Date: Tue, 30 Sep 2025 17:10:14 +0530 [thread overview]
Message-ID: <20250930114018.78215-21-sudhakar@linux.ibm.com> (raw)
In-Reply-To: <20250930114018.78215-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: Daniel Kiper <daniel.kiper@oracle.com>
---
docs/grub.texi | 327 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 327 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index b87a32ea9..00a9cfbfa 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 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 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 to generate a SHA-256 hash of a binary file using
+OpenSSL 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 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 block adding the distrusted
+certificates to the db list in the future.
+
+@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 binary/certificate hash from the file @var{hash_file}
+and add it to GRUB's internal dbx list of distrusted binary/certificate hashes.
+These hashes are used to ensure that the distrusted binary hashes/certificates
+are rejected during Linux kernel/GRUB module binary hashes and appended signatures validation
+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. Also, these hashes are used to block adding the distrusted
+binary hashes and certificates to the db list in the future.
+
+The @option{-b} (@option{--binary-hash}) can be used to specify binary hash file and
+@option{-c} (@option{--cert-hash}) can be used to specify certificate hash file.
+
+Here is an example to generate a hash of a binary and a certificate using
+OpenSSL 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 locked down 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 file:: Certificate and hash file signing
* Signing GRUB itself:: Ensuring the integrity of the GRUB core image
@end menu
@@ -9067,6 +9243,129 @@ 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. 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 to lockdown the GRUB. Signature verification
+ is performed and if signature verification fails, post the errors and
+ allow the boot to continue.
+@item @samp{2 - enforce}: Lockdown the GRUB 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 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,
+ post 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. Building the appendedsig module into the
+core GRUB image is recommended.
+
+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 the GRUB is locked down, user cannot change the value of the
+ @code{appendedsig_key_mgmt}.
+@item @samp{dynamic}: Enforce dynamic key management signature verification. When the GRUB is
+ locked down, 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}. Whether Secure Boot is enabled or not,
+it is possible to list the trusted certificates available at boot time using
+@command{append_list_db} (@pxref{append_list_db}). The distrusted certificates can be
+explicitly removed from the db using @command{append_add_dbx_cert} (@pxref{append_add_dbx_cert}).
+The 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 is not present or empty in PKS, static keys (built-in keys) are used as the default keys.
+Whether Secure Boot is enabled or not, it is possible to list the trusted certificates
+and binary hashes available at boot time using @command{append_list_db} (@pxref{append_list_db})
+and list the distrusted certificates and binary/certificate hashes available at boot time
+using @command{append_list_dbx} (@pxref{append_list_dbx}). The trusted certificates and
+binary hashes can be explicitly added to the db using the @command{append_add_db_cert}
+(@pxref{append_add_db_cert}) and @command{append_add_db_hash} (@pxref{append_add_db_hash}).
+The distrusted certificates can be explicitly added to the dbx using the
+@command{append_add_dbx_cert} (@pxref{append_add_dbx_cert}) and the distrusted
+certificate/binary hases can be explicitly added to the dbx using the @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 file}), 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 file}).
+The signature is verified by 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. SHA-256, SHA-384, or SHA-512 hashes of binary/certificate are only 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.
+
+The signatures created using SHA-256 or SHA-512 hash algorithm along with RSA keys of size 2048,
+3072, or 4096 bits are only 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 locked down (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 +9895,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 file
+@section Signing certificate and hash file
+The X.509 certificate (public key) file and hash file (binary/certificate hash file)
+can be signed with a Linux kernel module-style appended signature.
+
+The signer.key is your private key used for signing, signer.der is 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 your 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 your 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
next prev parent reply other threads:[~2025-09-30 11:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 11:39 [PATCH v13 00/20] Appended Signature Secure Boot Support for PowerPC Sudhakar Kuppusamy
2025-09-30 11:39 ` [PATCH v13 01/20] powerpc-ieee1275: Add support for signing GRUB with an appended signature Sudhakar Kuppusamy
2025-09-30 11:39 ` [PATCH v13 02/20] crypto: Move storage for grub_crypto_pk_* to crypto.c Sudhakar Kuppusamy
2025-09-30 11:39 ` [PATCH v13 03/20] pgp: Rename OBJ_TYPE_PUBKEY to OBJ_TYPE_GPG_PUBKEY Sudhakar Kuppusamy
2025-09-30 11:39 ` [PATCH v13 04/20] grub-install: Support embedding x509 certificates Sudhakar Kuppusamy
2025-09-30 11:39 ` [PATCH v13 05/20] appended signatures: Import GNUTLS's ASN.1 description files Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 06/20] appended signatures: Parse ASN1 node Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 07/20] appended signatures: Parse PKCS#7 signed data Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 08/20] appended signatures: Parse X.509 certificates Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 09/20] powerpc_ieee1275: Enter lockdown based on /ibm, secure-boot Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 10/20] appended signatures: Support verifying appended signatures Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 11/20] powerpc_ieee1275: Read the db and dbx secure boot variables Sudhakar Kuppusamy
2025-10-01 15:52 ` Daniel Kiper
2025-09-30 11:40 ` [PATCH v13 12/20] appended signatures: Introducing key management environment variable Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 13/20] appended signatures: Create db and dbx lists Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 14/20] appended signatures: Using db and dbx lists for signature verification Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 15/20] appended signatures: GRUB commands to manage the certificates Sudhakar Kuppusamy
2025-10-01 9:10 ` Sridhar Markonda
2025-09-30 11:40 ` [PATCH v13 16/20] appended signatures: GRUB commands to manage the hashes Sudhakar Kuppusamy
2025-10-01 9:09 ` Sridhar Markonda
2025-09-30 11:40 ` [PATCH v13 17/20] appended signatures: Verification tests Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 18/20] docs/grub: Document signing GRUB under UEFI Sudhakar Kuppusamy
2025-09-30 11:40 ` [PATCH v13 19/20] docs/grub: Document signing GRUB with an appended signature Sudhakar Kuppusamy
2025-09-30 11:40 ` Sudhakar Kuppusamy [this message]
2025-10-02 8:52 ` [PATCH v13 00/20] Appended Signature Secure Boot Support for PowerPC Avnish Chouhan
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=20250930114018.78215-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).