Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jeremy Cline 
On 03/12/2018 03:55 PM, Thiebaud Weksteen wrote:
> 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.biesheu...@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 +, 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, _guid, NULL,
>> _protocol);
>> @@ -104,9 +106,12 @@ void

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Ard Biesheuvel 
On 12 March 2018 at 19:55, Thiebaud Weksteen  wrote:
> 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.biesheu...@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 +, 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;
>> 
>>

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Thiebaud Weksteen 
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.biesheu...@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 +, 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, _guid, NULL,
>  _protocol);
>  @@ -104,9 +106,12 @@ void
>  efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jeremy Cline 
On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote:
> On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel 
> 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 +, 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, _guid, NULL,
 _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 **) _tbl);
 +   num_pages =

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jeremy Cline 
On 03/12/2018 01:30 PM, Ard Biesheuvel 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 +, 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, _guid, NULL,
>>> _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 **) _tbl);
>>> +   num_pages = DIV_ROUND_UP(sizeof(*log_tbl) + log_size, 
>>> EFI_PAGE_SIZE);
>>> +   status = efi_call_early(allocate_pages,
>>> +   EFI_ALLOCATE_ANY_PAGES,
>>> +

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Thiebaud Weksteen 
On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel 
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 +, 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, _guid, NULL,
> >> _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 **) _tbl);
> >> +   num_pages = DIV_ROUND_UP(sizeof(*log_tbl) + log_size,
EFI_PAGE_SIZE);
> >> +   status =

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Ard Biesheuvel 
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 +, 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, _guid, NULL,
>> _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 **) _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,
>> +   _tbl_alloc);
>>
>> if (status != EFI_SUCCESS) {
>>

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jeremy Cline 
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 +, 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, _guid, NULL,
> _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 **) _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,
> +   _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 =

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Ard Biesheuvel 
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 +, 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, _guid, NULL,
_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 **) _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,
+   _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 =

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jeremy Cline 
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 +, 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.

Regards,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Ard Biesheuvel 
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 +, 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Paul Menzel 

Dear Jarkko,


On 03/12/18 11:17, Jarkko Sakkinen wrote:

On Sat, 2018-03-10 at 10:45 +, Thiebaud Weksteen wrote:

On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline  wrote:

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?


Check if the BIOS is up to date?


How would that help? The no regression policy demands, that Linux 
continues working on systems, where it worked before. So upgrading the 
firmware is no solution, is it? Until a solution is found, the commits 
should be reverted.



Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Regression from efi: call get_event_log before ExitBootServices

2018-03-12 Thread Jarkko Sakkinen 
On Sat, 2018-03-10 at 10:45 +, Thiebaud Weksteen wrote:
> On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline  wrote:
> > 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?

Check if the BIOS is up to date?

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ingo Molnar 

* Ard Biesheuvel  wrote:

> On 12 March 2018 at 09:26, Ingo Molnar  wrote:
> >
> > * Ingo Molnar  wrote:
> >
> >> > -static pgd_t *efi_pgd;
> >> > -
> >>
> >> Hm, so there's some interaction here with:
> >>
> >>   116fef640859: x86/mm/dump_pagetables: Add the EFI pagetable to the 
> >> debugfs 'page_tables' directory
> >>
> >> which is in tip:x86/mm.
> >>
> >> Could you please resolve that conflict? I'll sort out the topic branches
> >> afterwards.
> >
> > So I've resolved it the following way, I merged the conflicting commit into
> > tip:efi/core and applied the 3 unrelated patches from your series:
> >
> >  36b649760e94: efi: Use string literals for efi_char16_t variable 
> > initializers
> >  136d5d57e35c: efi/esrt: Fix handling of early ESRT table mapping
> >  7e904a91bf60: efi: Use efi_mm in x86 as well as ARM
> >  b0599e2801df: Merge branch 'x86/mm' into efi/core
> >
> > and pushed it out.
> >
> > So if you could resolve the two conflicting patches on top of 36b649760e94 
> > then we
> > should be good going forward.
> >
> 
> By 'resolve' you mean rebase and resend, right?

Yeah.

I expected it to probably be a bit more work than a regular rebase, because we 
grew a new efi_pgd user and I didn't want to trivialize the conflict resolution 
effort - hence the 'resolve the conflict' formulation! :-)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH rebased 2/2] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

2018-03-12 Thread Ard Biesheuvel 
From: Sai Praneeth 

Use helper function efi_switch_mm() to switch to/from efi_mm when
invoking any UEFI runtime services.

Likewise, we need to switch back to previous mm (mm context stolen
by efi_mm) after the above calls return successfully. We can use
efi_switch_mm() helper function only with x86_64 kernel and
"efi=old_map" disabled because, x86_32 and efi=old_map do not use
efi_pgd, rather they use swapper_pg_dir.

Signed-off-by: Sai Praneeth Prakhya 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
Reviewed-by: Matt Fleming 
[ardb: add #include of sched/task.h for task_lock/_unlock]
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/include/asm/efi.h   | 25 +---
 arch/x86/platform/efi/efi_64.c   | 41 +++-
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 3 files changed, 33 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index c62443fa7d0a..cec5fae23eb3 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -70,14 +70,13 @@ extern asmlinkage u64 efi_call(void *fp, ...);
 #define efi_call_phys(f, args...)  efi_call((f), args)
 
 /*
- * Scratch space used for switching the pagetable in the EFI stub
+ * struct efi_scratch - Scratch space used while switching to/from efi_mm
+ * @phys_stack: stack used during EFI Mixed Mode
+ * @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
  */
 struct efi_scratch {
-   u64 r15;
-   u64 prev_cr3;
-   pgd_t   *efi_pgt;
-   booluse_pgd;
-   u64 phys_stack;
+   u64 phys_stack;
+   struct mm_struct*prev_mm;
 } __packed;
 
 #define arch_efi_call_virt_setup() \
@@ -87,11 +86,8 @@ struct efi_scratch {
__kernel_fpu_begin();   \
firmware_restrict_branch_speculation_start();   \
\
-   if (efi_scratch.use_pgd) {  \
-   efi_scratch.prev_cr3 = __read_cr3();\
-   write_cr3((unsigned long)efi_scratch.efi_pgt);  \
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(_mm); \
 })
 
 #define arch_efi_call_virt(p, f, args...)  \
@@ -99,10 +95,8 @@ struct efi_scratch {
 
 #define arch_efi_call_virt_teardown()  \
 ({ \
-   if (efi_scratch.use_pgd) {  \
-   write_cr3(efi_scratch.prev_cr3);\
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(efi_scratch.prev_mm); \
\
firmware_restrict_branch_speculation_end(); \
__kernel_fpu_end(); \
@@ -145,6 +139,7 @@ extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
 extern void efi_delete_dummy_variable(void);
+extern void efi_switch_mm(struct mm_struct *mm);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 29b267b8cb63..4f8a9c963fbb 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -82,9 +83,8 @@ pgd_t * __init efi_call_phys_prolog(void)
int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   save_pgd = (pgd_t *)__read_cr3();
-   write_cr3((unsigned long)efi_scratch.efi_pgt);
-   goto out;
+   efi_switch_mm(_mm);
+   return NULL;
}
 
early_code_mapping_set_exec(1);
@@ -156,8 +156,7 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
pud_t *pud;

[PATCH rebased 1/2] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ard Biesheuvel 
From: Sai Praneeth 

Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.

Signed-off-by: Sai Praneeth Prakhya 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
Reviewed-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/mm/debug_pagetables.c |  6 +++---
 arch/x86/platform/efi/efi_64.c | 18 +-
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/mm/debug_pagetables.c b/arch/x86/mm/debug_pagetables.c
index 51a6f92da2bf..225fe2f0bfec 100644
--- a/arch/x86/mm/debug_pagetables.c
+++ b/arch/x86/mm/debug_pagetables.c
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,13 +74,12 @@ static const struct file_operations ptdump_curusr_fops = {
 #endif
 
 #if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
-extern pgd_t *efi_pgd;
 static struct dentry *pe_efi;
 
 static int ptdump_show_efi(struct seq_file *m, void *v)
 {
-   if (efi_pgd)
-   ptdump_walk_pgd_level_debugfs(m, efi_pgd, false);
+   if (efi_mm.pgd)
+   ptdump_walk_pgd_level_debugfs(m, efi_mm.pgd, false);
return 0;
 }
 
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 29425b6c98a7..29b267b8cb63 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -191,8 +191,7 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
early_code_mapping_set_exec(0);
 }
 
-pgd_t *efi_pgd;
-EXPORT_SYMBOL_GPL(efi_pgd);
+EXPORT_SYMBOL_GPL(efi_mm);
 
 /*
  * We need our own copy of the higher levels of the page tables
@@ -205,7 +204,7 @@ EXPORT_SYMBOL_GPL(efi_pgd);
  */
 int __init efi_alloc_page_tables(void)
 {
-   pgd_t *pgd;
+   pgd_t *pgd, *efi_pgd;
p4d_t *p4d;
pud_t *pud;
gfp_t gfp_mask;
@@ -233,6 +232,7 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   efi_mm.pgd = efi_pgd;
mm_init_cpumask(_mm);
init_new_context(NULL, _mm);
 
@@ -248,6 +248,7 @@ void efi_sync_low_kernel_mappings(void)
pgd_t *pgd_k, *pgd_efi;
p4d_t *p4d_k, *p4d_efi;
pud_t *pud_k, *pud_efi;
+   pgd_t *efi_pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return;
@@ -341,7 +342,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
unsigned long pfn, text, pf;
struct page *page;
unsigned npages;
-   pgd_t *pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
@@ -351,8 +352,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 * this value is loaded into cr3 the PGD will be decrypted during
 * the pagetable walk.
 */
-   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
-   pgd = efi_pgd;
+   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(pgd);
 
/*
 * It can happen that the physical address of new_memmap lands in memory
@@ -422,7 +422,7 @@ static void __init __map_region(efi_memory_desc_t *md, u64 
va)
 {
unsigned long flags = _PAGE_RW;
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
@@ -526,7 +526,7 @@ void __init parse_efi_setup(u64 phys_addr, u32 data_len)
 static int __init efi_update_mappings(efi_memory_desc_t *md, unsigned long pf)
 {
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
int err1, err2;
 
/* Update the 1:1 mapping */
@@ -623,7 +623,7 @@ void __init efi_dump_pagetable(void)
if (efi_enabled(EFI_OLD_MEMMAP))
ptdump_walk_pgd_level(NULL, swapper_pg_dir);
else
-   ptdump_walk_pgd_level(NULL, efi_pgd);
+   ptdump_walk_pgd_level(NULL, efi_mm.pgd);
 #endif
 }
 
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ard Biesheuvel 
On 12 March 2018 at 09:26, Ingo Molnar  wrote:
>
> * Ingo Molnar  wrote:
>
>> > -static pgd_t *efi_pgd;
>> > -
>>
>> Hm, so there's some interaction here with:
>>
>>   116fef640859: x86/mm/dump_pagetables: Add the EFI pagetable to the debugfs 
>> 'page_tables' directory
>>
>> which is in tip:x86/mm.
>>
>> Could you please resolve that conflict? I'll sort out the topic branches
>> afterwards.
>
> So I've resolved it the following way, I merged the conflicting commit into
> tip:efi/core and applied the 3 unrelated patches from your series:
>
>  36b649760e94: efi: Use string literals for efi_char16_t variable initializers
>  136d5d57e35c: efi/esrt: Fix handling of early ESRT table mapping
>  7e904a91bf60: efi: Use efi_mm in x86 as well as ARM
>  b0599e2801df: Merge branch 'x86/mm' into efi/core
>
> and pushed it out.
>
> So if you could resolve the two conflicting patches on top of 36b649760e94 
> then we
> should be good going forward.
>

By 'resolve' you mean rebase and resend, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ingo Molnar 

* Ingo Molnar  wrote:

> > -static pgd_t *efi_pgd;
> > -
> 
> Hm, so there's some interaction here with:
> 
>   116fef640859: x86/mm/dump_pagetables: Add the EFI pagetable to the debugfs 
> 'page_tables' directory
> 
> which is in tip:x86/mm.
> 
> Could you please resolve that conflict? I'll sort out the topic branches 
> afterwards.

So I've resolved it the following way, I merged the conflicting commit into 
tip:efi/core and applied the 3 unrelated patches from your series:

 36b649760e94: efi: Use string literals for efi_char16_t variable initializers
 136d5d57e35c: efi/esrt: Fix handling of early ESRT table mapping
 7e904a91bf60: efi: Use efi_mm in x86 as well as ARM
 b0599e2801df: Merge branch 'x86/mm' into efi/core

and pushed it out.

So if you could resolve the two conflicting patches on top of 36b649760e94 then 
we 
should be good going forward.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ingo Molnar 

* Ard Biesheuvel  wrote:

> From: Sai Praneeth 
> 
> Since the previous patch added support for efi_mm, let's handle efi_pgd
> through efi_mm and remove global variable efi_pgd.
> 
> Signed-off-by: Sai Praneeth Prakhya 
> Cc: "Lee, Chun-Yi" 
> Cc: Borislav Petkov 
> Cc: Tony Luck 
> Cc: Andy Lutomirski 
> Cc: Michael S. Tsirkin 
> Cc: Bhupesh Sharma 
> Cc: Ricardo Neri 
> Cc: Ravi Shankar 
> Tested-by: Bhupesh Sharma 
> Reviewed-by: Matt Fleming 
> Signed-off-by: Ard Biesheuvel 
> ---
>  arch/x86/platform/efi/efi_64.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 0045efe9947b..8881e601c32d 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -190,8 +190,6 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
>   early_code_mapping_set_exec(0);
>  }
>  
> -static pgd_t *efi_pgd;
> -

Hm, so there's some interaction here with:

  116fef640859: x86/mm/dump_pagetables: Add the EFI pagetable to the debugfs 
'page_tables' directory

which is in tip:x86/mm.

Could you please resolve that conflict? I'll sort out the topic branches 
afterwards.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL 0/5] more EFI changes for v4.17

2018-03-12 Thread Ard Biesheuvel 
The following changes since commit f779ca740f25c8a6a72d951334f9efc3158a318b:

  efi: Make const array 'apple' static (2018-03-09 09:30:35 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next

for you to fetch changes up to a6072c0ecf3a39e9eadfaea1477533fd24261b05:

  efi: use string literals for efi_char16_t variable initializers (2018-03-10 
11:05:19 +)


Second batch of EFI changes for v4.17:
- take 2 of 'use efi_switch_mm() on x86 instead of manipulating %cr3 directly'
- fix early memremap leak in ESRT code
- switch to L"xxx" notation for wide string literals


Ard Biesheuvel (2):
  efi/esrt: fix handling of early ESRT table mapping
  efi: use string literals for efi_char16_t variable initializers

Sai Praneeth (3):
  efi: Use efi_mm in x86 as well as ARM
  x86/efi: Replace efi_pgd with efi_mm.pgd
  x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

 arch/x86/boot/compressed/eboot.c  |  3 +-
 arch/x86/include/asm/efi.h| 26 ++
 arch/x86/platform/efi/efi_64.c| 59 +--
 arch/x86/platform/efi/efi_thunk_64.S  |  2 +-
 arch/x86/platform/efi/quirks.c|  8 +++--
 drivers/firmware/efi/arm-runtime.c|  9 -
 drivers/firmware/efi/efi.c|  9 +
 drivers/firmware/efi/esrt.c   | 17 +++--
 drivers/firmware/efi/libstub/Makefile |  2 +-
 drivers/firmware/efi/libstub/secureboot.c | 12 ++-
 drivers/firmware/efi/libstub/tpm.c|  7 ++--
 include/linux/efi.h   |  2 ++
 12 files changed, 72 insertions(+), 84 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

2018-03-12 Thread Ard Biesheuvel 
From: Sai Praneeth 

Use helper function efi_switch_mm() to switch to/from efi_mm when
invoking any UEFI runtime services.

Likewise, we need to switch back to previous mm (mm context stolen
by efi_mm) after the above calls return successfully. We can use
efi_switch_mm() helper function only with x86_64 kernel and
"efi=old_map" disabled because, x86_32 and efi=old_map do not use
efi_pgd, rather they use swapper_pg_dir.

Signed-off-by: Sai Praneeth Prakhya 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
Reviewed-by: Matt Fleming 
[ardb: add #include of sched/task.h for task_lock/_unlock]
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/include/asm/efi.h   | 25 +-
 arch/x86/platform/efi/efi_64.c   | 41 +++-
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 3 files changed, 33 insertions(+), 35 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index c62443fa7d0a..cec5fae23eb3 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -70,14 +70,13 @@ extern asmlinkage u64 efi_call(void *fp, ...);
 #define efi_call_phys(f, args...)  efi_call((f), args)
 
 /*
- * Scratch space used for switching the pagetable in the EFI stub
+ * struct efi_scratch - Scratch space used while switching to/from efi_mm
+ * @phys_stack: stack used during EFI Mixed Mode
+ * @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
  */
 struct efi_scratch {
-   u64 r15;
-   u64 prev_cr3;
-   pgd_t   *efi_pgt;
-   booluse_pgd;
-   u64 phys_stack;
+   u64 phys_stack;
+   struct mm_struct*prev_mm;
 } __packed;
 
 #define arch_efi_call_virt_setup() \
@@ -87,11 +86,8 @@ struct efi_scratch {
__kernel_fpu_begin();   \
firmware_restrict_branch_speculation_start();   \
\
-   if (efi_scratch.use_pgd) {  \
-   efi_scratch.prev_cr3 = __read_cr3();\
-   write_cr3((unsigned long)efi_scratch.efi_pgt);  \
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(_mm); \
 })
 
 #define arch_efi_call_virt(p, f, args...)  \
@@ -99,10 +95,8 @@ struct efi_scratch {
 
 #define arch_efi_call_virt_teardown()  \
 ({ \
-   if (efi_scratch.use_pgd) {  \
-   write_cr3(efi_scratch.prev_cr3);\
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(efi_scratch.prev_mm); \
\
firmware_restrict_branch_speculation_end(); \
__kernel_fpu_end(); \
@@ -145,6 +139,7 @@ extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
 extern void efi_delete_dummy_variable(void);
+extern void efi_switch_mm(struct mm_struct *mm);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 8881e601c32d..229af5bbecb8 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -81,9 +82,8 @@ pgd_t * __init efi_call_phys_prolog(void)
int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   save_pgd = (pgd_t *)__read_cr3();
-   write_cr3((unsigned long)efi_scratch.efi_pgt);
-   goto out;
+   efi_switch_mm(_mm);
+   return NULL;
}
 
early_code_mapping_set_exec(1);
@@ -155,8 +155,7 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)

[PATCH 4/5] efi/esrt: fix handling of early ESRT table mapping

2018-03-12 Thread Ard Biesheuvel 
As reported by Tyler, efi_esrt_init() will return without releasing the
ESRT table header mapping if it encounters a table with an unexpected
version. Replacing the 'return' with 'goto err_memunmap' would fix this
particular occurrence, but, as it turns out, the code is rather peculiar
to begin with:
- it never uses the header mapping after memcpy()'ing out its contents,
- it maps and unmaps the entire table without ever looking at the
  contents.

So let's refactor this code to unmap the table header right after the
memcpy() so we can get rid of the error handling path altogether, and
drop the second mapping entirely.

Cc: Peter Jones 
Reported-by: Tyler Baicar 
Signed-off-by: Ard Biesheuvel 
---
 drivers/firmware/efi/esrt.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
index c47e0c6ec00f..1ab80e06e7c5 100644
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -279,6 +279,7 @@ void __init efi_esrt_init(void)
}
 
memcpy(, va, sizeof(tmpesrt));
+   early_memunmap(va, size);
 
if (tmpesrt.fw_resource_version == 1) {
entry_size = sizeof (*v1_entries);
@@ -291,7 +292,7 @@ void __init efi_esrt_init(void)
if (tmpesrt.fw_resource_count > 0 && max - size < entry_size) {
pr_err("ESRT memory map entry can only hold the header. (max: 
%zu size: %zu)\n",
   max - size, entry_size);
-   goto err_memunmap;
+   return;
}
 
/*
@@ -304,7 +305,7 @@ void __init efi_esrt_init(void)
if (tmpesrt.fw_resource_count > 128) {
pr_err("ESRT says fw_resource_count has very large value %d.\n",
   tmpesrt.fw_resource_count);
-   goto err_memunmap;
+   return;
}
 
/*
@@ -315,18 +316,10 @@ void __init efi_esrt_init(void)
if (max < size + entries_size) {
pr_err("ESRT does not fit on single memory map entry (size: %zu 
max: %zu)\n",
   size, max);
-   goto err_memunmap;
+   return;
}
 
-   /* remap it with our (plausible) new pages */
-   early_memunmap(va, size);
size += entries_size;
-   va = early_memremap(efi.esrt, size);
-   if (!va) {
-   pr_err("early_memremap(%p, %zu) failed.\n", (void *)efi.esrt,
-  size);
-   return;
-   }
 
esrt_data = (phys_addr_t)efi.esrt;
esrt_data_size = size;
@@ -336,8 +329,6 @@ void __init efi_esrt_init(void)
efi_mem_reserve(esrt_data, esrt_data_size);
 
pr_debug("esrt-init: loaded.\n");
-err_memunmap:
-   early_memunmap(va, size);
 }
 
 static int __init register_entries(void)
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] x86/efi: Replace efi_pgd with efi_mm.pgd

2018-03-12 Thread Ard Biesheuvel 
From: Sai Praneeth 

Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.

Signed-off-by: Sai Praneeth Prakhya 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
Reviewed-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/platform/efi/efi_64.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 0045efe9947b..8881e601c32d 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -190,8 +190,6 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
early_code_mapping_set_exec(0);
 }
 
-static pgd_t *efi_pgd;
-
 /*
  * We need our own copy of the higher levels of the page tables
  * because we want to avoid inserting EFI region mappings (EFI_VA_END
@@ -203,7 +201,7 @@ static pgd_t *efi_pgd;
  */
 int __init efi_alloc_page_tables(void)
 {
-   pgd_t *pgd;
+   pgd_t *pgd, *efi_pgd;
p4d_t *p4d;
pud_t *pud;
gfp_t gfp_mask;
@@ -231,6 +229,7 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   efi_mm.pgd = efi_pgd;
mm_init_cpumask(_mm);
init_new_context(NULL, _mm);
 
@@ -246,6 +245,7 @@ void efi_sync_low_kernel_mappings(void)
pgd_t *pgd_k, *pgd_efi;
p4d_t *p4d_k, *p4d_efi;
pud_t *pud_k, *pud_efi;
+   pgd_t *efi_pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return;
@@ -339,7 +339,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
unsigned long pfn, text, pf;
struct page *page;
unsigned npages;
-   pgd_t *pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
@@ -349,8 +349,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 * this value is loaded into cr3 the PGD will be decrypted during
 * the pagetable walk.
 */
-   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
-   pgd = efi_pgd;
+   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(pgd);
 
/*
 * It can happen that the physical address of new_memmap lands in memory
@@ -420,7 +419,7 @@ static void __init __map_region(efi_memory_desc_t *md, u64 
va)
 {
unsigned long flags = _PAGE_RW;
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
@@ -524,7 +523,7 @@ void __init parse_efi_setup(u64 phys_addr, u32 data_len)
 static int __init efi_update_mappings(efi_memory_desc_t *md, unsigned long pf)
 {
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
int err1, err2;
 
/* Update the 1:1 mapping */
@@ -621,7 +620,7 @@ void __init efi_dump_pagetable(void)
if (efi_enabled(EFI_OLD_MEMMAP))
ptdump_walk_pgd_level(NULL, swapper_pg_dir);
else
-   ptdump_walk_pgd_level(NULL, efi_pgd);
+   ptdump_walk_pgd_level(NULL, efi_mm.pgd);
 #endif
 }
 
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] efi: use string literals for efi_char16_t variable initializers

2018-03-12 Thread Ard Biesheuvel 
Now that we unambiguously build the entire kernel with -fshort-wchar,
it is no longer necessary to open code efi_char16_t[] initializers as
arrays of characters, and we can move to the L"xxx" notation instead.

Cc: Arnd Bergmann 
Cc: Lukas Wunner 
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/boot/compressed/eboot.c  |  3 ++-
 arch/x86/platform/efi/quirks.c|  8 +---
 drivers/firmware/efi/libstub/Makefile |  2 +-
 drivers/firmware/efi/libstub/secureboot.c | 12 +++-
 drivers/firmware/efi/libstub/tpm.c|  7 ++-
 5 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index f2251c1c9853..47d3efff6805 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -421,9 +421,10 @@ static void retrieve_apple_device_properties(struct 
boot_params *boot_params)
}
 }
 
+static const efi_char16_t apple[] = L"Apple";
+
 static void setup_quirks(struct boot_params *boot_params)
 {
-   static efi_char16_t const apple[] = { 'A', 'p', 'p', 'l', 'e', 0 };
efi_char16_t *fw_vendor = (efi_char16_t *)(unsigned long)
efi_table_attr(efi_system_table, fw_vendor, sys_table);
 
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 1ef11c26f79b..36c1f8b9f7e0 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -75,7 +75,7 @@ struct quark_security_header {
u32 rsvd[2];
 };
 
-static efi_char16_t efi_dummy_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
+static const efi_char16_t efi_dummy_name[] = L"DUMMY";
 
 static bool efi_no_storage_paranoia;
 
@@ -105,7 +105,8 @@ early_param("efi_no_storage_paranoia", 
setup_storage_paranoia);
 */
 void efi_delete_dummy_variable(void)
 {
-   efi.set_variable(efi_dummy_name, _DUMMY_GUID,
+   efi.set_variable((efi_char16_t *)efi_dummy_name,
+_DUMMY_GUID,
 EFI_VARIABLE_NON_VOLATILE |
 EFI_VARIABLE_BOOTSERVICE_ACCESS |
 EFI_VARIABLE_RUNTIME_ACCESS,
@@ -182,7 +183,8 @@ efi_status_t efi_query_variable_store(u32 attributes, 
unsigned long size,
if (!dummy)
return EFI_OUT_OF_RESOURCES;
 
-   status = efi.set_variable(efi_dummy_name, _DUMMY_GUID,
+   status = efi.set_variable((efi_char16_t *)efi_dummy_name,
+ _DUMMY_GUID,
  EFI_VARIABLE_NON_VOLATILE |
  EFI_VARIABLE_BOOTSERVICE_ACCESS |
  EFI_VARIABLE_RUNTIME_ACCESS,
diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index 7b3ba40f0745..a34e9290a699 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -9,7 +9,7 @@ cflags-$(CONFIG_X86_32) := -march=i386
 cflags-$(CONFIG_X86_64):= -mcmodel=small
 cflags-$(CONFIG_X86)   += -m$(BITS) -D__KERNEL__ -O2 \
   -fPIC -fno-strict-aliasing -mno-red-zone \
-  -mno-mmx -mno-sse
+  -mno-mmx -mno-sse -fshort-wchar
 
 cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie
 cflags-$(CONFIG_ARM)   := $(subst -pg,,$(KBUILD_CFLAGS)) \
diff --git a/drivers/firmware/efi/libstub/secureboot.c 
b/drivers/firmware/efi/libstub/secureboot.c
index 959777ec8a77..8f07eb414c00 100644
--- a/drivers/firmware/efi/libstub/secureboot.c
+++ b/drivers/firmware/efi/libstub/secureboot.c
@@ -16,18 +16,12 @@
 
 /* BIOS variables */
 static const efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
-static const efi_char16_t efi_SecureBoot_name[] = {
-   'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0
-};
-static const efi_char16_t efi_SetupMode_name[] = {
-   'S', 'e', 't', 'u', 'p', 'M', 'o', 'd', 'e', 0
-};
+static const efi_char16_t efi_SecureBoot_name[] = L"SecureBoot";
+static const efi_char16_t efi_SetupMode_name[] = L"SetupMode";
 
 /* SHIM variables */
 static const efi_guid_t shim_guid = EFI_SHIM_LOCK_GUID;
-static efi_char16_t const shim_MokSBState_name[] = {
-   'M', 'o', 'k', 'S', 'B', 'S', 't', 'a', 't', 'e', 0
-};
+static const efi_char16_t shim_MokSBState_name[] = L"MokSBState";
 
 #define get_efi_var(name, vendor, ...) \
efi_call_runtime(get_variable, \
diff --git a/drivers/firmware/efi/libstub/tpm.c 
b/drivers/firmware/efi/libstub/tpm.c
index da661bf8cb96..2298560cea72 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -16,11 +16,8 @@
 #include "efistub.h"
 
 #ifdef CONFIG_RESET_ATTACK_MITIGATION
-static const efi_char16_t efi_MemoryOverWriteRequest_name[] = {
-   'M', 'e', 'm', 'o', 'r', 'y', 'O', 'v',

[PATCH 1/5] efi: Use efi_mm in x86 as well as ARM

2018-03-12 Thread Ard Biesheuvel 
From: Sai Praneeth 

Presently, only ARM uses mm_struct to manage efi page tables and efi
runtime region mappings. As this is the preferred approach, let's make
this data structure common across architectures. Specially, for x86,
using this data structure improves code maintainability and readability.

Signed-off-by: Sai Praneeth Prakhya 
Cc: "Lee, Chun-Yi" 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
Reviewed-by: Matt Fleming 
[ardb: don't #include the world to get a declaration of struct mm_struct]
Signed-off-by: Ard Biesheuvel 
---
 arch/x86/include/asm/efi.h | 1 +
 arch/x86/platform/efi/efi_64.c | 3 +++
 drivers/firmware/efi/arm-runtime.c | 9 -
 drivers/firmware/efi/efi.c | 9 +
 include/linux/efi.h| 2 ++
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index a399c1ebf6f0..c62443fa7d0a 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * We map the EFI regions needed for runtime services non-contiguously,
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index c310a8284358..0045efe9947b 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -231,6 +231,9 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   mm_init_cpumask(_mm);
+   init_new_context(NULL, _mm);
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 13561aeb7396..5889cbea60b8 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -31,15 +31,6 @@
 
 extern u64 efi_system_table;
 
-static struct mm_struct efi_mm = {
-   .mm_rb  = RB_ROOT,
-   .mm_users   = ATOMIC_INIT(2),
-   .mm_count   = ATOMIC_INIT(1),
-   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
-   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
-   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
-};
-
 #ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
 #include 
 
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 92b9e79e5da9..232f4915223b 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -75,6 +75,15 @@ static unsigned long *efi_tables[] = {
_attr_table,
 };
 
+struct mm_struct efi_mm = {
+   .mm_rb  = RB_ROOT,
+   .mm_users   = ATOMIC_INIT(2),
+   .mm_count   = ATOMIC_INIT(1),
+   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
+   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
+   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
+};
+
 static bool disable_runtime;
 static int __init setup_noefi(char *arg)
 {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index f5083aa72eae..f1b7d68ac460 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -966,6 +966,8 @@ extern struct efi {
unsigned long flags;
 } efi;
 
+extern struct mm_struct efi_mm;
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html