[syslinux] [PATCH] efi: Call ExitBootServices at least twice

[Gene Cumm]

On Tue, Nov 3, 2015 at 8:37 AM, Celelibi <celelibi at gmail.com> wrote:
> 2015-11-03 11:24 UTC+01:00, Gene Cumm <gene.cumm at gmail.com>:

>>> So, why not try a memory allocation anyway? It works on some
>>> implementations (including mine) despite being forbidden by the
>>> specification, but we're in this situation because the firmware was
>>> already not complying with the UEFI spec.
>>
>> If ExitBootServices is unsuccessful, UEFI firmware memory allocation
>> should still be valid.  I don't believe it's forbidden at all since
>> ExitBootServices() was NOT successful.
>
> I disagree with this. The documentation of ExitBootServices(), section
> 6.4, say (typo included):
> "If MapKey value is incorrect, ExitBootServices() returns
> EFI_INVALID_PARAMETER and GetMemoryMap() with ExitBootServices() must
> be called again. Firmware implementation may choose to do a partial
> shutdown of the boot services during the first call to
> ExitBootServices(). EFI OS loader should not make calls to any boot
> service function other then GetMemoryMap() after the first call to
> ExitBootServices()."
>
> And the memory allocation services are boot services. So I think it's
> pretty clear from the last sentence that we shouldn't use the memory
> allocation services after a failed call to ExitBootServices.
>
> When they say "first call", it's not "first successful call". And
> since the sentences before talk about how ExitBootServices can fail
> and must be called again, I think "first call" definitely include the
> case when this first call failed.

I somehow missed that when I was reading.  Thank you.

Given this, why not allocate a pool much larger than needed to prevent
the need to call AllocatePool() after the first attempted call to
ExitBootServices()?  Would it be better to be just additive?  Or
perhaps multiplicative with a minimum (ie, the greater of 16 or double
the suggested size)?  Is adding 4 the first round enough?  Or would
adding 8 or 16 be better?

-- 
-Gene