[EXTERNAL] Re: [edk2-devel] [PATCH] MdeModulePkg: Fix runtime panic in ValidateSetVariable()

[Laszlo Ersek]

On 12/03/20 12:25, Ard Biesheuvel wrote:
> On 12/3/20 11:39 AM, Laszlo Ersek wrote:
>> On 12/01/20 22:12, Bret Barkelew via groups.io wrote:
>>> Getting caught up on emails from last week. I wanted to say thanks for the good catch and the good patch in my absence!
>>> Sorry for the oversight. :-/
>>
>> It happens. It's not great that I didn't get to regression-testing
>> earlier during the HFF. It's even less great that I chalked it up to a
>> guest kernel issue initially.
>>
>> What *is* great however is that James kept pushing and fixed it! :)
>>
>> MemoryAllocationLib is tricky. The abstraction it provides is a bit
>> "deceptive", IMO. There's an argument for removing support, between the
>> existing instances of this lib class, for *runtime* DXE drivers
>> altogether. In runtime DXE drivers, just force programmers to spell out
>> gBS, and the desired memory type. In other module types (PEIMs, DXE and
>> UEFI drivers, and SMM drivers), there is no ambiguity whether the
>> allocated memory survives into OS runtime. (Well, AllocateReservedPool()
>> complicates matters a bit, but it's not used frequently.)
>>
>> Another sign that MemoryAllocationLib is a leaky abstraction is commit
>> 1d733f731f968 -- in the SMM instance, AllocatePool() allocates SMRAM,
>> but FreePool() is supposed to be able to release both SMRAM and normal
>> RAM :( Something seems really fishy there, as one would expect calling
>> FreePool() only on what AllocatePool() returned earlier in the *same
>> module*. Since AllocatePool() only returns SMRAM in an SMM driver, why
>> would FreePool() *have* to release normal RAM? Oof.
>>
> 
> I thought traditional SMM drivers could call DXE protocols before end of
> DXE, no? Some boot services return pool allocated memory that has to be
> freed by the caller (e.g., LocateHandleBuffer())

Yes, and in that case, the SMM driver should release the memory with
gBS->FreePool(), not FreePool(). The fact that FreePool() in the SMM
instance of MemoryAllocationLib copes, since commit 1d733f731f968, is a
misfeature, IMO.

(Or even better, the SMM driver should release the memory with
SystemTable->BootServices->FreePool(), as having the "gBS" global
variable in the SMM module is apparently sometimes seen as a liability;
see SmmServicesTableLibConstructor() in
"MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.c".)

Thanks
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#68291): https://edk2.groups.io/g/devel/message/68291
Mute This Topic: https://groups.io/mt/78644930/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-