[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] x86/emul: Poision the stubs with debug traps



On 30/03/17 13:08, Jan Beulich wrote:
>>>> On 30.03.17 at 13:56, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 20/03/17 11:50, Jan Beulich wrote:
>>>>>> On 20.03.17 at 11:58, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> ...rather than leaving fragments of old instructions in place.  This 
>>>> reduces
>>>> the chances of something going further-wrong (as the debug trap will be 
>>>> caught
>>>> and terminate the guest) in a cascade-failure where we end up executing the
>>>> instruction fragments.
>>>>
>>>> Before:
>>>>     (XEN) d2v0 exception 6 (ec=0000) in emulation stub (line 6239)
>>>>     (XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90
>>>>
>>>> After:
>>>>     (XEN) d3v0 exception 6 (ec=0000) in emulation stub (line 6239)
>>>>     (XEN) d3v0 stub: c4 e1 44 77 c3 cc cc cc cc cc cc cc cc cc cc
>>>>
>>>> To make this work, the int3 handler needs to be extended to attempt 
>>>> recovery
>>>> rather than simply returning back to Xen context.  This is a good general
>>>> precaution anyway, as nothing good will happen from letting Xen blindly
>>>> execute over 0xcc's.
>>> I partly disagree: It can be a very useful thing to not have to rebuild
>>> Xen with hard coded INT3 invocations removed/re-added between
>>> runs with or without a debugger attached.
>> What possible usecase is this for?  If you don't already modify
>> do_int3(), use of embedded int3's are of no use.
> How are they not, with an external debugger attached? (I admit
> that I have no idea in what good or bad a state the external
> debugger support code is that we have.)

I have never succeeded at using the external debugger facilities, but I
have only tried once or twice.

If you do have an external debugger attached, you don't need embedded
int3's to start with, and you'd still hit the debugger_trap_*() calls
before dying.

If you don't have an external debugger attached, ignoring int3's is very
poor behaviour.  The fact that it ever worked is a bug IMO.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.