[edk2-devel] [PATCH v1 1/1] ArmPkg: DefaultExceptionHandlerLib: Do Not Allocate Memory

[Oliver Smith-Denny]

On 8/2/2023 9:06 AM, Ard Biesheuvel wrote:
> On Tue, 1 Aug 2023 at 00:04, Oliver Smith-Denny
> <osde at linux.microsoft.com> wrote:
>>
>> If gST->ConOut is available when Arm's DefaultExceptionHandler
>> is running, AsciiPrint will get called to attempt to print to
>> ConOut, in addition to the serial output.
>>
>> AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which
>> in turn calls AllocatePool to allocate a buffer to convert
>> the Ascii input string to a Unicode string to pass to
>> ConOut->OutputString.
>>
>> Per the comment on DefaultExceptionHandler, we should not be
>> allocating memory in the exception handler, as this can cause
>> the exception handler to fail if we had a memory exception or
>> the system state is such that we cannot allocate memory.
>>
>> It has been observed on ArmVirtQemu that exceptions generated
>> in the memory handling code will fail to output the stack dump
>> and CPU state that is critical to debugging because the
>> AllocatePool will fail.
>>
>> This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to
>> not allocate memory when ConOut is available and instead use
>> stack memory to convert the Ascii string needed for SerialPortWrite
>> to the Unicode string needed for ConOut->OutputString. Correspondingly,
>> ArmVirtQemu can now output the stack dump and CPU state when hitting
>> an exception in memory code.
>>
>> GitHub PR: https://github.com/tianocore/edk2/pull/4703
>>
>> Cc: Leif Lindholm <quic_llindhol at quicinc.com>
>> Cc: Ard Biesheuvel <ardb+tianocore at kernel.org>
>> Cc: Sami Mujawar <sami.mujawar at arm.com>
>> Cc: Gerd Hoffmann <kraxel at redhat.com>
>>
>> Signed-off-by: Oliver Smith-Denny <osde at linux.microsoft.com>
> 
> Thanks a lot for fixing this.
> 
> Is calling into gST->ConOut guaranteed to be safe in this regard? Or
> is it still best effort?
> 
> 

Yeah, this is something I worried about when fixing this. It is very
much best effort, because there are no guarantees that OutputString will
not allocate memory (or some other such unsafe operation in an exception
handler). With the ability to BYO ConOut stack and the complications
with graphics that can be involved here, I personally would be happy to
drop the ConOut call entirely and rely on the serial output.

In my testing, this did work on ArmVirtQemu and I can envision a case
where having the ConOut output would be nice, but I tend towards lets
keep the exception handler as simple as possible and make sure we get
the useful information dumped out.

Another option would be to keep this change but move the ConOut calls
to after all of the serial output, so that if we do get a recursive
exception in ConOut, at least we got our serial output.

Let me know what you think, happy to spin up a v2.

Thanks,
Oliver


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