This patch changes set_variables() so that it can use an external
environment block when one is present. The variable next_entry is
written into the external block, env_block is treated as read only, and
all other variables are written into the normal file based envblk.
A cleanup step is added to handle cases where GRUB at runtime writes
variables into the external block because file based updates are not
safe on a copy on write filesystem such as Btrfs. For example, the
savedefault command can update saved_entry, and on Btrfs GRUB will place
that update in the external block instead of the file envblk. If an
older copy remains in the external block, it would override the newer
value from the file envblk when GRUB first loads the file and then
applies the external block on top of it. To avoid this, whenever
a variable is updated in the file envblk, any same named key in
the external block is deleted.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds the function fs_envblk_write to update the reserved
environment block on disk. The helper takes an in memory envblk buffer
and writes it back to the device at the location defined by the
fs_envblk specification. It performs size checks and uses file sync to
ensure that the updated data is flushed.
The helper is also added into the fs_envblk ops table, together with the
open helper from the previous patch. With this change the basic input
and output path for an external environment block is complete. The
choice of which variables should be written externally will be handled
by later patches.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds the logic to locate and open an environment block that
is stored in a reserved area on the device. It introduces the function
fs_envblk_open() together with helper routines to read the block pointed
to by the env_block variable, and to create the block on disk when it
does not exist yet. When a block is created, the code records its
location inside the file based envblk by setting env_block in block list
syntax of offset plus size in sectors.
The env_block variable acts as a link from the file envblk to the raw
disk region so that later runs of grub-editenv can follow it and access
the external block. The helper is exposed through a small ops table
attached to fs_envblk so that later patches can call
fs_envblk->ops->open() without touching core code again. At this stage
variables are still stored in the file envblk and no redirection has
been applied.
In relation to this, the fs_envblk_spec table defines the file-system
specific layout of the reserved raw blocks used for environment storage.
It is prepared to facilitate integration in grub-editenv, with Btrfs to
be added in the future once its reserved area is defined.
An fs_envblk_init() helper is added to prepare it for using the ops with
its associated data context if the feature is available. It is not used
yet, but will be used later when a filesystem and its device are probed
to initialize the fs_envblk handle and enable access to the feature.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add unit tests for %zd, %zu and %zx to verify size_t and ssize_t
formatting matches system snprintf().
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add support for the "z" length modifier in the printf code. This allows
printing of size_t and ssize_t values using %zu, %zd and related
formats. The parser maps "z" to the correct integer width based on
sizeof(size_t).
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The --hw-accel option has been added to cryptomount to speed up
decryption by temporarily enabling hardware-specific instruction
sets (e.g., AVX, SSE) in libgcrypt.
A new feature, "feature_gcry_hw_accel", is also introduced to mark the
availability of the new option.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Enable hardware acceleration for the gcry_sha512 module when building
for the x86_64 EFI target.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Enable hardware acceleration for the gcry_sha256 module when building
for the x86_64 EFI target.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There is no prototype of _gcry_sha256_transform_intel_shaext() defined
in the header or libgcrypt-grub/cipher/sha256.c, and gcc may complain
the missing-prototypes error when compiling sha256-intel-shaext.c.
Declare the prototype in sha256-intel-shaext.c to avoid the error.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Implement _gcry_get_hw_features() and enable hardware feature detection
for x86_64.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Copy the selected x86_64 assembly files to support hardware
acceleration for sha512.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Copy the selected x86_64 assembly files to support hardware
acceleration for sha256.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Implement the necessary functions to dynamically enable SSE and AVX
on x86_64 EFI systems when the hardware is capable.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces the generic functions to manage the hardware
features in libgcrypt. These functions are stubs for future
platform-specific implementations:
- grub_gcry_hwf_enabled() returns __gcry_use_hwf which indicates if
the hardware features are enabled specifically by grub_enable_gcry_hwf(),
- grub_enable_gcry_hwf() invokes the architecture specific enablement
functions and sets __gcry_use_hwf to true,
- grub_reset_gcry_hwf() invokes the architecture specific reset
functions and sets __gcry_use_hwf to false.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To enable hardware acceleration, this commit ports the feature detection
logic from libgcrypt. This allows us to check if the compiler supports
specific assembly instructions, including SSSE3, Intel SHA extensions,
SSE4.1, AVX, AVX2, AVX512, and BMI2.
To simplify the initial implementation, support for x86_64 feature
detection is currently limited to the x86_64 EFI target.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The previous PBKDF2 implementation used grub_crypto_hmac_buffer() which
allocates and frees an HMAC handle on every call. This approach caused
significant performance overhead slowing down the boot process considerably.
This commit refactors the PBKDF2 code to use the new HMAC functions
allowing the HMAC handle and its buffers to be allocated once and reused
across multiple operations. This change significantly reduces disk
unlocking time.
In a QEMU/OVMF test environment this patch reduced the time to unlock
a LUKS2 (*) partition from approximately 15 seconds to 4 seconds.
(*) PBKDF2 SHA256 with 3454944 iterations.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To enable more efficient buffer reuse for HMAC operations three new
functions have been introduced. This change prevents the need to
reallocate memory for each HMAC operation:
- grub_crypto_hmac_reset(): reinitializes the hash contexts in the HMAC handle,
- grub_crypto_hmac_final(): provides the final HMAC result without freeing the
handle allowing it to be reused immediately,
- grub_crypto_hmac_free(): deallocates the HMAC handle and its associated memory.
To further facilitate buffer reuse ctx2 is now included within the HMAC handle
struct and the initialization of ctx2 is moved to grub_crypto_hmac_init().
The intermediate hash states, ctx and ctx2, for the inner and outer padded
keys are now cached. The grub_crypto_hmac_reset() restores these cached
states for new operations which avoids redundant hashing of the keys.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Gary Lin <glin@suse.com>
Tested-By: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When both "dest" and "src" are aligned, copying the data in grub_addr_t
sized chunks is more efficient than a byte-by-byte copy.
Also tweak __aeabi_memcpy(), __aeabi_memcpy4(), and __aeabi_memcpy8(),
since grub_memcpy() is not inline anymore.
Optimization for unaligned buffers was omitted to maintain code
simplicity and readability. The current chunk-copy optimization
for aligned buffers already provides a noticeable performance
improvement (*) for Argon2 keyslot decryption.
(*) On my system, for a LUKS2 keyslot configured with a 1 GB Argon2
memory requirement, this patch reduces the decryption time from
22 seconds to 12 seconds.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Given that the LUKS1 test already covers PBKDF2, the default KDF for the
LUKS2 test has been switched to Argon2id to ensure both algorithms are
validated.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-By: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Refactor the Argon2 tests to enable the module build and integrate the
tests into function_test.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-By: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Copy the Argon2 test function, check_argon2(), from t-kdf.c in libgcrypt
to grub-core/tests/argon2_test.c.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-By: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Leverage the new grub_crypto_argon2() function to add support for the
Argon2i and Argon2id KDFs in LUKS2.
Signed-off-by: Gary Lin <glin@suse.com>
Tested-By: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces grub_crypto_argon2() which leverages the
_gcry_kdf_*() functions from libgcrypt to provide Argon2 support.
Due to the dependency of the _gcry_kdf_*() functions, the order of
"ldadd" entries have to be tweaked in Makefile.util.def so that the
linker can discover these functions.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use grub_divmod64() for the 64-bit modulus to prevent creation of
special division calls such as __umoddi3() and __aeabi_uldivmod() on
32-bit platforms.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gpg_err_code_from_errno() requires libgcrypt_wrap/mem.c which is not in
Makefile.utilgcry.def. This commit replaces gpg_err_code_from_errno()
with GPG_ERR_* to avoid the build errors.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The hash_buffers() functions are disabled in GRUB by default but the
Argon2 implementation requires hash_buffers() for BLAKE2b-512.
This commit implements argon2_blake2b_512_hash_buffers() as the
replacement of _gcry_digest_spec_blake2b_512.hash_buffers().
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces the necessary changes to crypto.h in preparation
for implementing Argon2 support via the generic KDF functions, _gcry_kdf_*():
- add new GPG error types required by kdf.c,
- declare _gcry_digest_spec_blake2b_512 to enable BLAKE2b-512 digest calculations,
- define the gcrypt KDF algorithm IDs for Argon2,
- add the prototypes of _gcry_kdf_*() functions.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The import_gcry.py script now imports kdf.c from libgcrypt. To isolate
the Argon2 implementation, all unrelated functions have been removed.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A menu entry with an empty title leads to an out-of-bounds access at
"ch = src[len - 1]", i.e., "src" is empty and "len" is zero. So, fixing
this by checking the menu entry title length and throwing an error if
the length is zero.
Signed-off-by: Sridhar Markonda <sridharm@linux.ibm.com>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A test is introduced to cap PCR 1 and track the PCR 1 value before and
after key unsealing.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To prevent a sealed key from being unsealed again, a common and
straightforward method is to "cap" the key by extending the associated
PCRs. When the PCRs associated with the sealed key are extended, TPM will
be unable to unseal the key, as the PCR values required for unsealing no
longer match, effectively rendering the key unusable until the next
system boot or a state where the PCRs are reset to their expected values.
To cap a specific set of PCRs, simply append the argument '-c pcr_list'
to the tpm2_key_protector command. Upon successfully unsealing the key,
the TPM2 key protector will then invoke tpm2_protector_cap_pcrs(). This
function extends the selected PCRs with an EV_SEPARATOR event,
effectively "capping" them. Consequently, the associated key cannot be
unsealed in any subsequent attempts until these PCRs are reset to their
original, pre-capped state, typically occurring upon the next system
boot.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since there is no system firmware for grub-emu, the TPM2_PCR_Event
command becomes the only choice to implement grub_tcg2_cap_pcr().
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit implements grub_tcg2_cap_pcr() for ieee1275 with the
firmware function, 2hash-ext-log, to extend the target PCR with an
EV_SEPARATOR event and record the event into the TPM event log.
To avoid duplicate code, ibmvtpm_2hash_ext_log() is moved to tcg2.c
and exported as a global function.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit implements grub_tcg2_cap_pcr() for EFI by using the UEFI
TCG2 protocol, HashLogExtendEvent, to extend the specified PCR with an
EV_SEPARATOR event and ensure the event will be recorded properly in the
TPM event log.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This commit introduces the definition of grub_tcg2_cap_pcr(), a new
function designed to enhance the security of sealed keys. Its primary
purpose is to "cap" a specific PCR by extending it with an EV_SEPARATOR
event. This action cryptographically alters the PCR value, making it
impossible to unseal any key that was previously sealed to the original
PCR state. Consequently, the sealed key remains protected against
unauthorized unsealing attempts until the associated PCRs are reset to
their initial configuration, typically occurring during a subsequent
system boot.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The TPM2_PCR_Event command is introduced to tss2 to allow the user to
extend a specific PCR. The related data structure and unmarshal function
are also introduced.
However, simply invoking TPM2_PCR_Event does not automatically record
the event into the TPM event log. The TPM event log is primarily
maintained by the system firmware (e.g., BIOS/UEFI). Therefore, for most
standard use cases, the recommended method for extending PCRs and
ensuring proper event logging is to utilize the system firmware
functions.
There are specific scenarios where direct use of TPM2_PCR_Event becomes
necessary. For instance, in environments lacking system firmware support
for PCR extension, such as the grub-emu, TPM2_PCR_Event serves as the
only available method to extend PCRs.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Linux kernel's struct bootparams provides a field at offset 0x140
for storing an EDID header. Copy the video adapter's data to the field.
The edid_info field was added in 2003 (see "[FBDEV] EDID support from
OpenFirmware on PPC platoforms and from the BIOS on intel platforms."),
but only got useable in 2004 (see "[PATCH] Fix EDID_INFO in zero-page").
The boot protocol was at version 2.03 at that time.
The field was never used much, but with the recent addition of the efidrm
and vesadrm drivers to the kernel, it becomes much more useful. As with
the initial screen setup, these drivers can make use of the provided
EDID information for basic display output.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "permissions" field of hfsplus files is only used by Mac OS X. This
causes GRUB to skip reading files created by Mac OS 9, since their
file mode is read as unknown. Instead, assume files with zero mode
are regular files.
From Technote 1150:
The traditional Mac OS implementation of HFS Plus does not use the
permissions field. Files created by traditional Mac OS have the
entire field set to 0.
Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Following warnings are thrown during libgrcypt and bluski doc build:
grub.texi:4744: warning: node next pointer for `gcry_arcfour_module' is `gcry_blake2_module' but next is `gcry_aria_module' in menu
grub.texi:4744: warning: node prev pointer for `gcry_arcfour_module' is `gcry_aria_module' but prev is `functional_test_module' in menu
grub.texi:4751: warning: node prev pointer for `gcry_blake2_module' is `gcry_arcfour_module' but prev is `gcry_aria_module' in menu
grub.texi:8532: warning: node next pointer for `trust' is `unset' but next is `uki' in menu
grub.texi:8549: warning: node next pointer for `unset' is `uki' but next is `verify_detached' in menu
grub.texi:8549: warning: node prev pointer for `unset' is `trust' but prev is `uki' in menu
grub.texi:8557: warning: node next pointer for `uki' is `verify_detached' but next is `unset' in menu
grub.texi:8557: warning: node prev pointer for `uki' is `unset' but prev is `trust' in menu
grub.texi:8600: warning: node prev pointer for `verify_detached' is `uki' but prev is `unset' in menu
Fix order of gcry_aria_module and unset nodes.
Signed-off-by: Sridhar Markonda <sridharm@linux.ibm.com>
Reviewed-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
During command registration, grub_register_command_prio() returns
a 0 when there is a failure in memory allocation. In such a situation,
calls to grub_unregister_{command(), extcmd()} during command
unregistration will result in dereferencing a NULL pointer.
Perform explicit NULL check in both unregister helpers to prevent
undefined behaviour due to a NULL pointer dereference.
Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The call was added in the 1.1 revision of the spec, 1.0 does
not have it, and there are some machines out there with a TPM2
and a UEFI firmware that only supports version 1.0, so the
call fails in those cases. Check the reported version before
calling get_active_pcr_banks().
See Table 4 in section 6.2 of the TCG EFI Protocol Specification:
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
Fixes: f326c5c47 (commands/bli: Set LoaderTpm2ActivePcrBanks runtime variable)
Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
Reviewed-by: Andrew Hamilton <adhamilt@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With the following change, we see standard (grub_dprintf) and
error (grub_error) logs with the function name embedded (see below)
into the log which is particular useful when debugging:
commands/efi/tpm.c:grub_tpm_measure:281:tpm: log_event, pcr = 8, size = 0xb,
Including one more field on the print log impacts the binary sizes
and in turn their respective distro packages. For Fedora rpm packages
the increase is 20k approximately.
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GRUB's TCP stack assigns source ports for outgoing connections starting
at 21550 and increments sequentially by 1 (e.g., 21550, 21551, ...).
While this generally works, it can lead to failures if the system
reboots rapidly and reuses the same source port too soon.
This issue was observed on powerpc-ieee1275 platforms using CAS (Client
Architecture Support) reboot. In such cases, loading the initrd over
HTTP may fail with connection timeouts. Packet captures show the failed
connections are flagged as "TCP Port Number Reused" by Wireshark.
The root cause is that GRUB reuses the same port shortly after reboot,
while the server may still be tracking the previous connection in
TIME_WAIT. This can result in the server rejecting the connection
attempt or responding with a stale ACK or RST, leading to handshake
failure.
This patch fixes the issue by introducing a time based source port
selection strategy. Instead of always starting from port 21550, GRUB now
computes an initial base port based on the current RTC time, divided
into 5 minute windows. The purpose of this time based strategy is to
ensure that GRUB avoids reusing the same source port within a 5 minute
window, thereby preventing collisions with stale server side connection
tracking that could interfere with a new TCP handshake.
A step size of 8 ensures that the same port will not be reused across
reboots unless GRUB opens more than 8 TCP connections per second on
average, something that is highly unlikely. In typical usage, a GRUB
boot cycle lasts about 15 seconds and may open fewer than 100
connections total, well below the reuse threshold. This makes the
approach robust against short reboot intervals while keeping the logic
simple and deterministic.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.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>
Signing GRUB for firmware that verifies an appended signature is a
bit fiddly. I don't want people to have to figure it out from scratch
so document it here.
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>
Before adding information about how GRUB is signed with an appended
signature scheme, it's worth adding some information about how it
can currently be signed for UEFI.
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>
These tests are run through all_functional_test and test a range
of commands and behaviours.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
