Andrew,
You remind me that GDB and WinDbg both set bp internally for some features,
like "run to line ###", "step out". It is too hard for end user of UDK Debugger
to know the details of Debugger implementation and avoid doing "bad" things
(run to line ###, or step out).
We need to clear the DR registers and the timer used by DebugAgent. For the
software breakpoints using "int 3/cc", we have no way to restore them. But it's
ok to leave them as "cc" because the memory will be overwritten by OS. The only
exception is user sets a software bp in runtime service implementation. We have
to ask end-user to not do such things in the document. Or you have better idea?
Thanks,
Ray
From: Andrew Fish [mailto:[email protected]]
Sent: Wednesday, August 29, 2012 1:29 AM
To: [email protected]
Subject: Re: [edk2] DebugAgentLib question
Ray,
How do you know that the debugger does not automatically set breakpoints to
enable features? We have these kind of features in our debugger.
How do you clear the breakpoints? You need the debugger to stop prior to a
state change to clear the breakpoints, and to do this you you need the callback.
As far as I can tell all the calls to SaveAndSetDebugTimerInterrupt (FALSE),
that are not internal to the debugger, imply the debugger needs to undo any
state that could cause an exception (S/W breakpoints injected in the code, and
H/W breakpoint registers). If you look most of the calls to
SaveAndSetDebugTimerInterrupt (FALSE) have to do with an IDT switch and the new
IDT will cause a system crash
All the following points could cause crashes if the debugger leaves behind
state that causes an exception.
BootScriptEcecutorDxe: S3BootScriptExecutorEntryFunction()
S3ResumePei: S3RestoreConfig2()
CapsulePei: Thunk32To64()
DXE IPL: HandOffToDxeCore() with PcdDxeIplSwitchToLongMode
DXE Core: CoreExitBootServices()
CSM: GenericLegacyBoot()
Thus the debugger should only leave behind system state that can cause an
exception if it is hooked into the IDT. If the IDT is going to be changed then
the debugger needs to be notified. The debugger should not hard crash the
system into a jmp $ loop if I as a user pick the wrong watchpoint to set in the
debugger, of set a breakpoint on _ModuleEntryPoint in the DXE Core.
At this point I'm working around this issue by disabling all debugger exception
sources when SaveAndSetDebugTimerInterrupt (FALSE) is called. This is a much
bigger issue on X64 than on ARM or IPF as the 32-bit to 64-bit mode changes are
causing most of the issues. The OS boot issue is generic.
Andrew Fish
On Aug 28, 2012, at 9:44 AM, Ni, Ruiyu wrote:
Andrew,
In my opinion, if user sets software/hardware breakpoints and doesn't clear
them before booting to runtime. The result is undefined. User is responsible to
clear the breakpoints.
Thanks,
Ray
From: Andrew Fish [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Wednesday, August 29, 2012 12:21 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] DebugAgentLib question
Jeff,
The location you note is very far into PEI Core Init. In the DXE Core the
debugger is initialized right away, and in my local copy that is what I did in
the PEI Core. Initing early implies you need to use InitializeDebugAgent ()
Function callback so the debugger context can be stored on the stack. Given the
context is on the stack the 2nd call is needed to migrate the data to the stack
that ends up on moved into system memory. It kind of makes sense if you think
about it that if you want to start the debugger as early as possible in the PEI
Core you need to use a scheme that is similar to the SEC scheme.
I'm a little worried that almost every place we have a call to
SaveAndSetInterruptTimer () to disable the interrupt timer we need to also stop
the debugger. What happens if the debugger sets a port 0x80 trap and the IDT is
switched over for DXE IPL or S3 resume? Seems like you will crash in the stub
IDTs set up for these new environments. I'm thinking of making my
implementation of SaveAndSetDebugTimerInterrupt() turn off the debug registers
too, but this is not really a clean solution. We could add an InitFlag to
IntializeDebugAgent() for this, but I'm worried this will start to leak chunks
of the debugger that are not needed into various modules (DXE IPL, S3 Resume,
...).
Andrew Fish
On Aug 27, 2012, at 10:40 PM, Fan, Jeff wrote:
Andrew,
We have defined one InitFlag DEBUG_AGENT_INIT_PEI, which could be used by one
PEI module to initialize Debug Agent. I think it also could be used by PEI Core.
For example,
It could be invoked in PEI Core at below,
//
// Initialize PEI Core Services
//
InitializeMemoryServices (&PrivateData, SecCoreData, OldCoreData);
InitializePpiServices (&PrivateData, OldCoreData);
InitializeDebugAgent (DEBUG_AGENT_INIT_PEI, NULL, NULL);
Debug Agent Library instance could initialize Debug Agent and use HOB service
to save some private contents. HOB services will be consistence before/after
physical memory is ready.
Debug Agent Library instance also could register one PPI callback function on
gEfiPeiMemoryDiscoveredPpiGuid, to send memory ready packet to HOST when memory
is ready.
Does it meet your requirement?
Now I think DEBUG_AGENT_INIT_PEI_POSTMEM is not needed. If you encountered some
issue when enabling Debug Agent in PEI Core module, we could revisit this flag
at that time.
Thanks!
Jeff
From: Andrew Fish [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Tuesday, August 28, 2012 2:45 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] DebugAgentLib question
Jeff,
Since we need to add an InitFlag, can we also add DEBUG_AGENT_INIT_PEI_POSTMEM?
The code base does not seem to offer the option of having the debugger be part
of the PEI Core, which I think is a design bug. I could envision system
architectures where it is not wise to have a debugger integrated into the
SEcurity Core, but a debugger for PEI is till wanted. So I think the PEI Core
should have InitializeDebugagent() calls for DEBUG_AGENT_INIT_PEI, and
DEBUG_AGENT_INIT_PEI_POSTMEM.
Thanks,
Andrew Fish
On Aug 27, 2012, at 1:15 AM, Fan, Jeff wrote:
Andrew,
Good catch! Now, only Debug Timer interrupt was disabled before hand-off to OS.
Besides Debug Registers, we also need to think how to clear the soft break
points set by WinDbg or GDB in runtime services or in SMM code. One new
InitFlag could be introduced to help HOST debugger to clear such break points
if needed.
Jeff
From: Andrew Fish [mailto:[email protected]]<mailto:[mailto:[email protected]]>
Sent: Saturday, August 25, 2012 3:01 AM
To: [email protected]<mailto:[email protected]>
Subject: [edk2] DebugAgentLib question
#define DEBUG_AGENT_INIT_PREMEM_SEC 1
#define DEBUG_AGENT_INIT_POSTMEM_SEC 2
#define DEBUG_AGENT_INIT_DXE_CORE 3
#define DEBUG_AGENT_INIT_SMM 4
#define DEBUG_AGENT_INIT_ENTER_SMI 5
#define DEBUG_AGENT_INIT_EXIT_SMI 6
#define DEBUG_AGENT_INIT_S3 7
#define DEBUG_AGENT_INIT_DXE_AP 8
#define DEBUG_AGENT_INIT_PEI 9
#define DEBUG_AGENT_INIT_DXE_LOAD 10
#define DEBUG_AGENT_INIT_DXE_UNLOAD 11
I was looking for a InitializeDebugAgent() InitFlag to turn off the debugger on
boot? I was worried that if debug register were active when the OS boots that
may cause an issue. Is it safe to assume the OS would clear debug registers
prior to switching over the IDT? That seems to be implied by this interface?
Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Include/Library/DebugAgentLib.h
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
