public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@arm.com>,
	devel@edk2.groups.io, bret.barkelew@microsoft.com,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>
Cc: "Liming Gao (Byosoft address)" <gaoliming@byosoft.com.cn>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [PATCH] MdeModulePkg: Fix runtime panic in ValidateSetVariable()
Date: Fri, 4 Dec 2020 00:33:21 +0100	[thread overview]
Message-ID: <1d87dccc-8c9f-a5ba-5d3c-146e969a6035@redhat.com> (raw)
In-Reply-To: <d9e3c4b8-5d2f-faef-3932-6b65441263cb@arm.com>

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


      reply	other threads:[~2020-12-03 23:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 20:13 [PATCH] MdeModulePkg: Fix runtime panic in ValidateSetVariable() James Bottomley
2020-11-25 21:00 ` Laszlo Ersek
2020-11-26  1:23   ` 回复: " gaoliming
     [not found]   ` <164AEA4706B9EEF6.8857@groups.io>
2020-11-27  0:58     ` 回复: [edk2-devel] " gaoliming
2020-11-25 21:05 ` Ard Biesheuvel
2020-11-25 21:17   ` Laszlo Ersek
2020-12-01 21:12     ` [EXTERNAL] Re: [edk2-devel] " Bret Barkelew
2020-12-03 10:39       ` Laszlo Ersek
2020-12-03 11:25         ` Ard Biesheuvel
2020-12-03 23:33           ` Laszlo Ersek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d87dccc-8c9f-a5ba-5d3c-146e969a6035@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox