Listed in categories X86 Internals Articles
    Most recent version 0.1
    Most recent release date November 11, 2010
    Description Super-secret debug capabilities of Atlon XP and better AMD processors

    Here unveiled by Czernobyl aka Czerno - Mail This

    PAGE IN CONSTRUCTION
    You can help Yes, YOU - Please DO correct grammar and other English language mistakes - Please add formatting, bold, italics... as needed for better accessibility - Please contact me over any errors inaccuracies complement to the technical contents - If you own a 64-bit AMD processor, please DO check and report any differences. Contents are intended to be released at a later time under liberal copyright copyleft options. Please do NOT make the contents available elsewhere BEFORE it is READY to be unleashed I retain the 'moral' ownership rights.

    TODO mucho...

    Summary AMD processors Athlon XP and better have included firmware-based debugging features that expand greatly over standard, architecturally defined capabilities of X86. For some reason though, AMD has been tightly secretive about these features hint of their existence was gained by glancing at CBID's page URL below . Herein will be uncovered what was found through direct experimentation, in the hope it may be useful to software developers, possibly included in future debuggers or debugger plug-ins. I'll use the term expanded for the capabilities covered here, since the term debug extensions was already taken. The item is WORK IN PROGRESS, but USABLE hence released AS IS Author can be contacted email, or PM, or public thread on the reversing board Note All addresses values are hexadecimal unless noted otherwise.

    The following four new machine specific registers MSR are involved in the expanded debug facilities. All those MSRs are password protected against casual access read write access RDMSR WRMSR to the registers is granted only if EDI holds the correct password value, viz. EDI 9C5A203A. Otherwise, a GPF exception occurs.

    All these registers default reset values are zero.

        * Control C001_1024 width 8 bits Data_Match
        * C001_1025 width 32 AMD64 64 Data_Mask
        * C001_1026 - ditto - Address_Mask
        * C001_1027 width 12 bits

    Let's start by looking at the Control MSR DbgCtrlMSR2, C001_1024 since it is the key to the new features. The low 8 bits can be set reset - only bit 0 and bit 1 will be examined here. The other bits had no effect in my preliminary, limited experimentation and will be left at zero. Readers are invited to further investigate report A - When Control 0 default , the AMD processor's debug firmware operates as defined by X86 architectural specs. In order to switch on the expanded debug capabilities, we must set Control MSR's bit 1. IOW, set Control 2 or 3, more on this later .

    B - When Control 2 binary 10 , the operation of any breakpoint defined in DR0 is modified as will be described. DR1 to DR3 breakpoints aren't affected at all . DR0-based breakpoint is now controlled by the new registers Addres_Mask, Data_Match and Data_Mask, in addition to DR7. General notions about the Mask MSRs both in Data_Mask and Address_Mask, a 1 bit means don't care .

    Formally, when a comparison of two values addresses needs to occur under mask, the Mask is ANDed to both and then the compare is done. A match occurs if the masked values are equal. A mask value of zero thus is equivalent to no mask. A mask of all ones makes match occur on just one value considering compare length . Note for Address_Masks, those only make sense that are binary zeroes followed by zero or more binary ones. Not sure if that is enforced by the AMD firmware Now let's examine expanded DR0-breakpoint operation Instruction breakpoints DR7 type 0 break occurs at any address which matches the BP address in DR0 under Address_Mask. Recall Address_Mask is significant to 12 bits only. Thus the widest possible Address_Mask is 0x0FFF, meaning breakpoint fault 01 will occur at any address matching DR0 within a 4-k bytes 'page' Data Memory DR7 types 1 and 3 and I O type 2 breakpoints the memory or port address specified in the instruction is checked against DR0 under Address_Mask, making it possible to match up to 4-k contiguous byte addresses If address match occurs, and read write type also matches for memory BP, then the data read written to, with length as specified in DR7, are compared to Data_Match under Data_Mask. Processor will break trap 01 if a match occurs. Reminder IO breakpoints need CR4_DE set.

    C- When Control 3 binary 11 , the operation is identical to case B, except the condition for data matching is reversed, i.e. break occurs on NON-MATCH. Address matching is unchanged, which also implies instruction BPs are insensitive to the low bit of the Control MSR.

    D- Warning Control 1, or setting bit zero without bit 1 also set, should be considered reserved dangerous unused. Even though I know how I believe the debugging firmware operates under that setting, I won't document it. Nothing useful there adventurous types are not forced to take my word for it .

    Copyright c 2010 by Czerno.
    Knowledge is free.