Received: by 10.213.65.68 with SMTP id h4csp259838imn; Mon, 12 Mar 2018 12:56:54 -0700 (PDT) X-Google-Smtp-Source: AG47ELvY4AoejicH1so+iphX06e9So/vS72bfZe0sUZ1rtiWSmk8gsTiFt6kcOh3wfkYUkdclCaF X-Received: by 10.99.102.5 with SMTP id a5mr7581362pgc.452.1520884614761; Mon, 12 Mar 2018 12:56:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520884614; cv=none; d=google.com; s=arc-20160816; b=Q6DPTUKbwf/BPNonulVSmQxnwLfQKBIIv2iNrtRGars/4v+8nkbxu0GvYAohGj7g4F V3jHRT1BPJlJJuGoDGIWyZjTaitO4UYZAvavgghCzmbFKdF5Lewvsc2jk4ti5Y4slo7h cLHZ3Uwuu0hYhETG4lKVBtFrT9xcPg+kFAuL7K3wATKUkYS6t4Cq8rQf6oFBx3ErONIy QmHm6p8guH8wX9KT1BwE6kKuMr5ceK6xXx7WyZ/5dJ31xs59n831lbEp7UiD8kpeMJSC QS51DiMLrTDVwiXeMXUGGoBm+d8TfMwmgxMBx2wYgTLRv3j7DgwOPmVSdgzZL0X6qlLb ky2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=CwrBWmaVtIZSp/kVqoRHhojsd+x4xOPUiF4uoanlHVQ=; b=ohSNVWXleyqBLwhRMegOuhr8N/04eLsuze0mZAgQXOeIGONVpNIgXwDQx90xQ9eKoc tfQpHUChLWjnl8qrrsdLFjPBNIte28oSPu7K+VCOJaI+4rmf1zGlh0qhC4A0eTieO+Xf sOtsgSxikBuDlbvone3sNcMpCzdsodB/IDhe3P4uVhZ7008w9gdXizk0tbhpH56OPts6 ajnpKp5qdgfNSOsNCQfuv6IfeAtEgAP64oa1fiLv3hm5uP422V6p4cBOzdLbhaUxs3EN AWXiBEusDky0NLbx6iF8IinfjCvnWu8LE2hAYiQJikdFQzNxDyZ1U74AXD/ybCobDfue Mtgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OI3IjYqM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bi2-v6si6547339plb.645.2018.03.12.12.56.40; Mon, 12 Mar 2018 12:56:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OI3IjYqM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932308AbeCLTzv (ORCPT + 99 others); Mon, 12 Mar 2018 15:55:51 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:52248 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932217AbeCLTzt (ORCPT ); Mon, 12 Mar 2018 15:55:49 -0400 Received: by mail-it0-f65.google.com with SMTP id k135so12753177ite.2 for ; Mon, 12 Mar 2018 12:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwrBWmaVtIZSp/kVqoRHhojsd+x4xOPUiF4uoanlHVQ=; b=OI3IjYqMZSOQG3tre4EBhRgxj07UvHyBfuqcJ7KkSfwh7R4lu6MD98oy+Xy8NhPvli g4M8RmPWkRk/ufIIpbqB30hJncyoZMdDxLEqlnVUbb31R06awR8MFQUF9KeKoQ5okRl2 4KhkKoKNrZd8rPiT5JmW0RHvIvHK+fvGvYQhTsEKvwRnLVzfV9jIRkhYGRHmtWA5alKQ bWE6xmgohO2SjbWiHrB/vJpgBdjNzsEXB+Vgj4mgLAFb4UWTzqHQv0oj5DTs33QhjyoS K3rKih5kWv0b05garNZCKhRJijQ0rJCpN44obTS2WdN2srj9v46HJC5k9kpqd3Ut7BTK BHpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CwrBWmaVtIZSp/kVqoRHhojsd+x4xOPUiF4uoanlHVQ=; b=pqPkRhE21hYDu8D6isKM8wjOLgNwklVFxkx2kL8xxkq/59b6LOkNhflYnz0M+E0mLA yDM9HxModMt3a7Gb71M/MSfdz2m+5Yt3mzOab2cAAbX9mjQKaQBqjcjE9fhBIh3X/m4i b3DnfnhcqJQxz8Lqcy/m2SnuwLarlOY6zDUx+/0eAVpWnUkl+Mrgm6RqD9mX6c5vir3G DWxB4YQdbyr7zm1GgRBbc2hYNiXqwpQQpiYEvPDsOG9i+dwk6/88sG4zHNvzCpmJC2f8 JmKnsMxFjUVn+jw/Eh4jPF65qx3JgnX6jpe3bqSyR5Q5BGVDdZUGeiyisW/zobRiOIRW 4zOQ== X-Gm-Message-State: AElRT7GzsUokNTJb2mfwVJaJ5e5niA5f03GhAxKuuHC5kXycSQ4pKchd oD0bwHK9G/LT4w6ZeFzIh7D8rpu+8RHSdEGRptLjxQ== X-Received: by 10.36.177.68 with SMTP id c4mr10289347itj.92.1520884547994; Mon, 12 Mar 2018 12:55:47 -0700 (PDT) MIME-Version: 1.0 References: <01000161fc0b4755-df0621f4-ab5d-479a-b425-adf98427a308-000000@email.amazonses.com> <0100016206a68850-bd5c96b3-f275-46ea-98b1-1317e02a5d6e-000000@email.amazonses.com> <29c1640a-cf19-ca19-7de9-96f202edfb5a@redhat.com> <010001620bafa06b-41525407-603e-40a9-ba11-6033b2f5dcc7-000000@email.amazonses.com> <010001621a9e5069-0b1a6328-97e4-4396-9438-b90f5b8c82a4-000000@email.amazonses.com> <010001621b287e42-58955302-cc14-4212-b7b0-e6e358633dab-000000@email.amazonses.com> <010001621b7ce5a3-b80c55b8-be68-4b44-ab52-4949e8ddb8d0-000000@email.amazonses.com> In-Reply-To: <010001621b7ce5a3-b80c55b8-be68-4b44-ab52-4949e8ddb8d0-000000@email.amazonses.com> From: Thiebaud Weksteen Date: Mon, 12 Mar 2018 19:55:36 +0000 Message-ID: Subject: Re: Regression from efi: call get_event_log before ExitBootServices To: Jeremy Cline , hdegoede@redhat.com Cc: Ard Biesheuvel , Javier Martinez Canillas , Jarkko Sakkinen , linux-efi@vger.kernel.org, linux-integrity@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote: > On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote: > > On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel < ard.biesheuvel@linaro.org> > > wrote: > > > >> On 12 March 2018 at 17:01, Jeremy Cline wrote: > >>> On 03/12/2018 10:56 AM, Ard Biesheuvel wrote: > >>>> On 12 March 2018 at 14:30, Jeremy Cline wrote: > >>>>> On 03/12/2018 07:08 AM, Ard Biesheuvel wrote: > >>>>>> On 10 March 2018 at 10:45, Thiebaud Weksteen > > wrote: > >>>>>>> On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline > > wrote: > >>>>>>> > >>>>>>>> On Fri, Mar 09, 2018 at 10:43:50AM +0000, Thiebaud Weksteen wrote: > >>>>>>>>> Thanks a lot for trying out the patch! > >>>>>>>>> > >>>>>>>>> Please don't modify your install at this stage, I think we are > > hitting a > >>>>>>>>> firmware bug and that would be awesome if we can fix how we are > >>>>>>> handling it. > >>>>>>>>> So, if we reach that stage in the function it could either be > > that: > >>>>>>>>> * The allocation did not succeed, somehow, but the firmware still > >>>>>>> returned > >>>>>>>>> EFI_SUCCEED. > >>>>>>>>> * The size requested is incorrect (I'm thinking something like a > > 1G of > >>>>>>>>> log). This would be due to either a miscalculation of log_size > >>>>>>> (possible) > >>>>>>>>> or; the returned values of GetEventLog are not correct. > >>>>>>>>> I'm sending a patch to add checks for these. Could you please > > apply and > >>>>>>>>> retest? > >>>>>>>>> Again, thanks for helping debugging this. > >>>>>>> > >>>>>>>> No problem, thanks for the help :) > >>>>>>> > >>>>>>>> With the new patch: > >>>>>>> > >>>>>>>> Locating the TCG2Protocol > >>>>>>>> Calling GetEventLog on TCG2Protocol > >>>>>>>> Log returned > >>>>>>>> log_location is not empty > >>>>>>>> log_size != 0 > >>>>>>>> log_size < 1M > >>>>>>>> Allocating memory for storing the logs > >>>>>>>> Returned from memory allocation > >>>>>>>> Copying log to new location > >>>>>>> > >>>>>>>> And then it hangs. I added a couple more print statements: > >>>>>>> > >>>>>>>> diff --git a/drivers/firmware/efi/libstub/tpm.c > >>>>>>> b/drivers/firmware/efi/libstub/tpm.c > >>>>>>>> index ee3fac109078..1ab5638bc50e 100644 > >>>>>>>> --- a/drivers/firmware/efi/libstub/tpm.c > >>>>>>>> +++ b/drivers/firmware/efi/libstub/tpm.c > >>>>>>>> @@ -148,8 +148,11 @@ void > >>>>>>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >>>>>>>> efi_printk(sys_table_arg, "Copying log to new > > location\n"); > >>>>>>> > >>>>>>>> memset(log_tbl, 0, sizeof(*log_tbl) + log_size); > >>>>>>>> + efi_printk(sys_table_arg, "Successfully memset log_tbl to > > 0\n"); > >>>>>>>> log_tbl->size = log_size; > >>>>>>>> + efi_printk(sys_table_arg, "Set log_tbl->size\n"); > >>>>>>>> log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > >>>>>>>> + efi_printk(sys_table_arg, "Set log_tbl-version\n"); > >>>>>>>> memcpy(log_tbl->log, (void *) first_entry_addr, log_size); > >>>>>>> > >>>>>>>> efi_printk(sys_table_arg, "Installing the log into the > >>>>>>> configuration table\n"); > >>>>>>> > >>>>>>>> and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) + > > log_size);" > >>>>>>> > >>>>>>> Thanks. Well, it looks like the memory that is supposedly allocated > > is not > >>>>>>> usable. I'm thinking this is a firmware bug. > >>>>>>> Ard, would you agree on this assumption? Thoughts on how to proceed? > >>>>>>> > >>>>>> > >>>>>> I am rather puzzled why the allocate_pool() should succeed and the > >>>>>> subsequent memset() should fail. This does not look like an issue > > that > >>>>>> is intimately related to TPM2 support, rather an issue in the > > firmware > >>>>>> that happens to get tickled after the change. > >>>>>> > >>>>>> Would you mind trying replacing EFI_LOADER_DATA with > >>>>>> EFI_BOOT_SERVICES_DATA in the allocate_pool() call? > >>>>> > >>>>> Replacing EFI_LOADER_DATA with EFI_BOOT_SERVICES_DATA still hangs at > > the > >>>>> memset() call. > >>>>> > >>>> > >>>> Could you try the following please? (attached as well in case gmail > > mangles it) > >>>> > >>>> diff --git a/drivers/firmware/efi/libstub/tpm.c > >>>> b/drivers/firmware/efi/libstub/tpm.c > >>>> index 2298560cea72..30d960a344b7 100644 > >>>> --- a/drivers/firmware/efi/libstub/tpm.c > >>>> +++ b/drivers/firmware/efi/libstub/tpm.c > >>>> @@ -70,6 +70,8 @@ void > >>>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >>>> size_t log_size, last_entry_size; > >>>> efi_bool_t truncated; > >>>> void *tcg2_protocol; > >>>> + unsigned long num_pages; > >>>> + efi_physical_addr_t log_tbl_alloc; > >>>> > >>>> status = efi_call_early(locate_protocol, &tcg2_guid, NULL, > >>>> &tcg2_protocol); > >>>> @@ -104,9 +106,12 @@ void > >>>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >>>> } > >>>> > >>>> /* Allocate space for the logs and copy them. */ > >>>> - status = efi_call_early(allocate_pool, EFI_LOADER_DATA, > >>>> - sizeof(*log_tbl) + log_size, > >>>> - (void **) &log_tbl); > >>>> + num_pages = DIV_ROUND_UP(sizeof(*log_tbl) + log_size, > > EFI_PAGE_SIZE); > >>>> + status = efi_call_early(allocate_pages, > >>>> + EFI_ALLOCATE_ANY_PAGES, > >>>> + EFI_LOADER_DATA, > >>>> + num_pages, > >>>> + &log_tbl_alloc); > >>>> > >>>> if (status != EFI_SUCCESS) { > >>>> efi_printk(sys_table_arg, > >>>> @@ -114,6 +119,7 @@ void > >>>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >>>> return; > >>>> } > >>>> > >>>> + log_tbl = (struct linux_efi_tpm_eventlog *)(unsigned > > long)log_tbl_alloc; > >>>> memset(log_tbl, 0, sizeof(*log_tbl) + log_size); > >>>> log_tbl->size = log_size; > >>>> log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > >>>> @@ -126,7 +132,7 @@ void > >>>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >>>> return; > >>>> > >>>> err_free: > >>>> - efi_call_early(free_pool, log_tbl); > >>>> + efi_call_early(free_pages, log_tbl_alloc, num_pages); > >>>> } > >>>> > >>>> void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table_arg) > >>>> > >>> > >>> Hi Ard, > >>> > >>> When I apply this, it starts hanging at > >>> > >>> status = efi_call_proto(efi_tcg2_protocol, get_event_log, tcg2_protocol, > >>> EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2, > >>> &log_location, &log_last_entry, &truncated); > >>> > >>> rather than at the memset() call. > >>> > > > >> That is *very* surprising, given that the change only affects code > >> that executes after that. > > Hans, you said you configured the tablet to use the 32-bit version of grub instead of 64. Why's that? Jeremy, could you confirm if you are building the kernel in 64bit mode? Is your Android install working? (that is, what happens if you boot Boot0000)? > >> I understand how annoying this is for you, and I think we should try > >> to fix this, but reverting the patches outright isn't the solution > >> either. > > > >> Which UEFI vendor and version does your system report? > > > > You should be able to find this info using the "ver" command in the UEFI > > shell. > > The UEFI vendor is Insyde (see first message). > > > Ah, thanks! > EFI Specification Revision : 2.40 > EFI Vendor : INSYDE Corp. > EFI Revision : 21573.83 > Regards, > Jeremy