Paulo Alcantara <pa...@paulo.ac> writes: >> 3) I am a little surprised on PeCoffSearchImageBase() issue. >> >> We have 4 PeCoffSearchImageBase() call in each arch. DumpImageModuleNames() >> calls twice and DumpStacktrace() calls twice. >> Do you know which specific one triggers the zero address #PF issue? >> >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\Ia32\ArchExceptionHandler.c(547): >> ImageBase = PeCoffSearchImageBase (Eip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\Ia32\ArchExceptionHandler.c(613): >> ImageBase = PeCoffSearchImageBase (Eip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\Ia32\ArchExceptionHandler.c(682): >> ImageBase = PeCoffSearchImageBase (Eip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\Ia32\ArchExceptionHandler.c(741): >> ImageBase = PeCoffSearchImageBase (Eip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\ArchExceptionHandler.c(540): >> ImageBase = PeCoffSearchImageBase (Rip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\ArchExceptionHandler.c(613): >> ImageBase = PeCoffSearchImageBase (Rip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\ArchExceptionHandler.c(710): >> ImageBase = PeCoffSearchImageBase (Rip); >> >> C:\home\EdkIIGit\edk2\UefiCpuPkg\Library\CpuExceptionHandlerLib\X64\ArchExceptionHandler.c(779): >> ImageBase = PeCoffSearchImageBase (Rip); >> > > When I saw the #PF when testing stack trace in SMM, I was running out of > time and I just saved the log file with the trace. I'm attaching the > log for you, but I'm still going to look into that issue when time > permits.
Forgot to attach the log file. Done. :-)
!!!! X64 Exception Type - 03(#BP - Breakpoint) CPU Apic ID - 00000000 !!!! RIP - 000000007FF48151, CS - 0000000000000038, RFLAGS - 0000000000000046 RAX - 0000000000000000, RCX - 000000007FEBB020, RDX - 0000000000040000 RBX - 0000000000000000, RSP - 000000007FF7B760, RBP - 000000007FF7B760 RSI - 000000007FF44018, RDI - 000000007FEBB018 R8 - 00000000000000FF, R9 - 0000000000048400, R10 - 00000000000000C9 R11 - 0000000000000069, R12 - 0000000000000000, R13 - 0000000000000000 R14 - 0000000000000000, R15 - 0000000000000000 DS - 0000000000000020, ES - 0000000000000020, FS - 0000000000000020 GS - 0000000000000020, SS - 0000000000000020 CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 000000007FF6C000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007FF6B000 000000000000004F, LDTR - 0000000000000000 IDTR - 000000007FF75000 00000000000001FF, TR - 0000000000000040 FXSAVE_STATE - 000000007FF7B3C0 Call trace: 0 0x000000007FF48151 @ 0x000000007FF46000+0x2151 (0x000000007FF7B760) in VariableSmm.dll 1 0x000000007FF54E35 @ 0x000000007FF46000+0xEE35 (0x000000007FF7B7D0) in VariableSmm.dll 2 0x000000007FF5659E @ 0x000000007FF46000+0x1059E (0x000000007FF7B800) in VariableSmm.dll 3 0x000000007FF4BCFE @ 0x000000007FF46000+0x5CFE (0x000000007FF7B840) in VariableSmm.dll 4 0x000000007FFE9BFA @ 0x000000007FFDB000+0xEBFA (0x000000007FF7B8A0) in PiSmmCore.dll 5 0x000000007FFEAAC4 @ 0x000000007FFDB000+0xFAC4 (0x000000007FF7B9C0) in PiSmmCore.dll 6 0x000000007FFEADD1 @ 0x000000007FFDB000+0xFDD1 (0x000000007FF7BA20) in PiSmmCore.dll 7 0x000000007FFE43F8 @ 0x000000007FFDB000+0x93F8 (0x000000007FF7BA90) in PiSmmCore.dll 8 0x000000007FFA8B9A @ 0x000000007FF9C000+0xCB9A (0x000000007FF7BD50) in PiSmmCpuDxeSmm.dll 9 0x000000007FFA9E92 @ 0x000000007FF9C000+0xDE92 (0x000000007FF7BDC0) in PiSmmCpuDxeSmm.dll !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! ExceptionData - 0000000000000000 I:0 R:0 U:0 W:0 P:0 PK:0 S:0 RIP - 000000007FFA1BBE, CS - 0000000000000038, RFLAGS - 0000000000010006 RAX - 000000007FF89FFC, RCX - 000000007FF8E149, RDX - FFFFFFFFFFFFFFFF RBX - 0000000000000000, RSP - 000000007FF7B1A0, RBP - 000000007FF7B1E0 RSI - 000000007FFA9E92, RDI - 000000007FF9C000 R8 - 0000000000000001, R9 - 0000000000000000, R10 - 0000000000000000 R11 - 0000000000000069, R12 - 0000000000000000, R13 - 0000000000000000 R14 - 0000000000000000, R15 - 0000000000000000 DS - 0000000000000020, ES - 0000000000000020, FS - 0000000000000020 GS - 0000000000000020, SS - 0000000000000020 CR0 - 0000000080010033, CR2 - 000000007FF89FFC, CR3 - 000000007FF6C000 CR4 - 0000000000000668, CR8 - 0000000000000000 DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 GDTR - 000000007FF6B000 000000000000004F, LDTR - 0000000000000000 IDTR - 000000007FF75000 00000000000001FF, TR - 0000000000000040 FXSAVE_STATE - 000000007FF76C60
Paulo >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paulo >>> Alcantara >>> Sent: Monday, January 15, 2018 8:23 AM >>> To: edk2-devel@lists.01.org >>> Cc: Rick Bramley <richard.bram...@hp.com>; Dong, Eric >>> <eric.d...@intel.com>; Kimon Berlin <kimon.ber...@hp.com>; Andrew Fish >>> <af...@apple.com>; Yao, Jiewen <jiewen....@intel.com>; Diego Medaglia >>> <diego.meag...@hp.com>; Laszlo Ersek <ler...@redhat.com> >>> Subject: [edk2] [RFC v5 0/8] Stack trace support in X64 exception handling >>> >>> Hi, >>> >>> This series adds stack trace support during IA32 and X64 CPU exceptions. >>> >>> Informations like back trace, stack contents and image module names >>> (that were part of the call stack) will be dumped out. >>> >>> The current limitation is that it relies on available frame pointers >>> (GCC only) in order to successfully unwind the stack. >>> >>> Jiewen, >>> >>> Thank you very much for your time on this. I've applied the changes you >>> suggested, as well as tested it on IA32 PAE paging mode - it worked as >>> expected. >>> >>> Other than that, I also tested the stack trace in SMM code by manually >>> calling CpuBreakPoint() and then it broke with another exception >>> (page fault). I didn't have much time to look into that, but what I've >>> observed is that the page fault ocurred during the search of PE/COFF >>> image base address (in PeCoffSearchImageBase). The function attempts to >>> search for the image base from "Address" through 0, so any of those >>> dereferenced addresses triggers the page fault. >>> >>> Do you know how we could fix that issue? Perhaps introducing a >>> AddressValidationLib (as Brian suggested previously) and use it within >>> PeCoffSearchImageBase()? >>> >>> I'd also like to thank Brian & Jeff for all the support! >>> >>> Thanks >>> Paulo >>> >>> Repo: https://github.com/pcacjr/edk2.git >>> Branch: stacktrace_v5 >>> >>> Cc: Rick Bramley <richard.bram...@hp.com> >>> Cc: Kimon Berlin <kimon.ber...@hp.com> >>> Cc: Diego Medaglia <diego.meag...@hp.com> >>> Cc: Andrew Fish <af...@apple.com> >>> Cc: Eric Dong <eric.d...@intel.com> >>> Cc: Laszlo Ersek <ler...@redhat.com> >>> Cc: Brian Johnson <brian.john...@hpe.com> >>> Cc: Jeff Fan <vanjeff_...@hotmail.com> >>> Cc: Jiewen Yao <jiewen....@intel.com> >>> Cc: Paulo Alcantara <pa...@hp.com> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Paulo Alcantara <pa...@paulo.ac> >>> --- >>> >>> v1 -> v2: >>> * Add IA32 arch support (GCC toolchain only) >>> * Replace hard-coded stack alignment value (16) with >>> CPU_STACK_ALIGNMENT. >>> * Check for proper stack and frame pointer alignments. >>> * Fix initialization of UnwoundStacksCount to 1. >>> * Move GetPdbFileName() to common code since it will be used by both >>> IA32 and X64 implementations. >>> >>> v2 -> v3: >>> * Fixed wrong assumption about "RIP < ImageBase" to start searching >>> for another PE/COFF image. That is, RIP may point to lower and >>> higher addresses for any other PE/COFF images. Both IA32 & X64. >>> (Thanks Andrew & Jiewen) >>> * Fixed typo: unwond -> unwound. Both IA32 & X64. (Thanks Brian) >>> >>> v3 -> v4: >>> * Validate all frame/stack pointer addresses before dereferencing them >>> as requested by Brian & Jiewen. >>> * Correctly print out IP addresses during the stack traces (by Jeff) >>> >>> v4 -> v5: >>> * Fixed address calculations and improved code as suggested by Jiewen. >>> * Fixed parameter validation as suggested by Brian. >>> * Tested stack stack with IA32 PAE paging mode. >>> >>> Paulo Alcantara (8): >>> UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support >>> UefiCpuPkg/CpuExceptionHandlerLib: Export GetPdbFileName() >>> UefiCpuPkg/CpuExceptionHandlerLib/Ia32: Add stack trace support >>> UefiCpuPkg/CpuExceptionHandlerLib: Add helper to validate memory >>> addresses >>> UefiCpuPkg/CpuExceptionHandlerLib: Ensure valid frame/stack pointers >>> UefiCpuPkg/CpuExceptionHandlerLib: Correctly print IP addresses >>> UefiCpuPkg/CpuExceptionHandlerLib: Validate memory address ranges >>> UefiCpuPkg/CpuExceptionHandlerLib: Add early check in >>> DumpStackContents >>> >>> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c >>> | 537 ++++++++++++++++++-- >>> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h >>> | 59 ++- >>> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | >>> 483 +++++++++++++++++- >>> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | >>> 426 +++++++++++++++- >>> 4 files changed, 1435 insertions(+), 70 deletions(-) >>> >>> -- >>> 2.14.3 >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
