Re: [Xen-devel] Fwd: Xen-4.1.6.1 backport for XSA156

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.11.15 at 18:07, <stefan.bader@xxxxxxxxxxxxx> wrote:
> On 20.11.2015 17:54, Jan Beulich wrote:
>>>>> On 20.11.15 at 17:15, <stefan.bader@xxxxxxxxxxxxx> wrote:
>>> So this is a quick hack I just tried and that keeps the HVM alive:
>>>
>>> @@ -1294,7 +1288,6 @@ void vmx_inject_hw_exception(int trap, i
>>>      switch ( trap )
>>>      {
>>>      case TRAP_debug:
>>> -        type = X86_EVENTTYPE_SW_EXCEPTION;
>>>          if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
>>>          {
>>>              __restore_debug_registers(curr);
>>> @@ -1302,6 +1295,13 @@ void vmx_inject_hw_exception(int trap, i
>>>          }
>>>          if ( cpu_has_monitor_trap_flag )
>>>              break;
>>> +        if ( curr->domain->debugger_attached )
>>> +        {
>>> +            /* Debug/Int3: Trap to debugger. */
>>> +            domain_pause_for_debugger();
>>> +            return;
>>> +        }
>>> +        break;
>>>      case TRAP_int3:
>>>          if ( curr->domain->debugger_attached )
>>>          {
>>>
>>> Though this looks like an ugly hack and probably is wrong in the other case 
>>> of
>>> TRAP_debug caused by an opcode...
>> 
>> Right, and I'm afraid this case doesn't get handled correctly even on
>> -unstable now. But apart from that aspect I think the change above
>> is okay.
> 
> Oh, ok. Thanks for the review. I guess then I go with that. At least this 
> does no longer crash.

Actually there's no problem with ICEBP - just like INTnn it isn't itself
interceptable (and the injection of vector 0x01 from the x86
emulator path can't fully distinguish between ICEBP and INT $1  in
these old versions anyway). So what you have should be good
enough, albeit I think I'll code it slightly differently (keeping the fall-
through in place).

Jan


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