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

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

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())