On 19 June 2018 at 21:50, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Commit 79832f0b5f71 ("efi/libstub/tpm: Initialize pointer variables to zero > for mixed mode") fixes a problem with the tpm code on mixed mode (64 bit > kernel on 32 bit UEFI), where 64-bit pointer variables are not fully > initialized by the 32-bit EFI code. > > The same problem applies to the efi_physical_addr_t variables which > are written by the get_event_log EFI call. > > This commit initializes these to 0 to, to ensure the upper 32 bits are > 0 in mixed mode. This fixes recent kernels sometimes hanging during > early boot on mixed mode UEFI systems. > efi_physical_addr_t is always a 64-bit type, regardless of mixed mode, so this smells like buggy firmware. Is the issue 100% reproducible? > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > --- > drivers/firmware/efi/libstub/tpm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c > index caa37a6dd9d4..a90b0b8fc69a 100644 > --- a/drivers/firmware/efi/libstub/tpm.c > +++ b/drivers/firmware/efi/libstub/tpm.c > @@ -64,7 +64,7 @@ static void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > efi_guid_t tcg2_guid = EFI_TCG2_PROTOCOL_GUID; > efi_guid_t linux_eventlog_guid = LINUX_EFI_TPM_EVENT_LOG_GUID; > efi_status_t status; > - efi_physical_addr_t log_location, log_last_entry; > + efi_physical_addr_t log_location = 0, log_last_entry = 0; > struct linux_efi_tpm_eventlog *log_tbl = NULL; > unsigned long first_entry_addr, last_entry_addr; > size_t log_size, last_entry_size; > -- > 2.17.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html