Re: [Xen-devel] [PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.09.15 at 17:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/09/15 16:25, Jan Beulich wrote:
>>>>> On 28.09.15 at 12:16, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> +void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
>>> +{
>>> +    v->arch.user_regs.eax = rsp->data.regs.x86.rax;
>>> +    v->arch.user_regs.ebx = rsp->data.regs.x86.rbx;
>>> +    v->arch.user_regs.ecx = rsp->data.regs.x86.rcx;
>>> +    v->arch.user_regs.edx = rsp->data.regs.x86.rdx;
>>> +    v->arch.user_regs.esp = rsp->data.regs.x86.rsp;
>>> +    v->arch.user_regs.ebp = rsp->data.regs.x86.rbp;
>>> +    v->arch.user_regs.esi = rsp->data.regs.x86.rsi;
>>> +    v->arch.user_regs.edi = rsp->data.regs.x86.rdi;
>>> +
>>> +    v->arch.user_regs.r8 = rsp->data.regs.x86.r8;
>>> +    v->arch.user_regs.r9 = rsp->data.regs.x86.r9;
>>> +    v->arch.user_regs.r10 = rsp->data.regs.x86.r10;
>>> +    v->arch.user_regs.r11 = rsp->data.regs.x86.r11;
>>> +    v->arch.user_regs.r12 = rsp->data.regs.x86.r12;
>>> +    v->arch.user_regs.r13 = rsp->data.regs.x86.r13;
>>> +    v->arch.user_regs.r14 = rsp->data.regs.x86.r14;
>>> +    v->arch.user_regs.r15 = rsp->data.regs.x86.r15;
>>> +
>>> +    v->arch.user_regs.eflags = rsp->data.regs.x86.rflags;
>> Shouldn't you sanitize the value? I can't immediately see anything
>> putting Xen at risk (but it also doesn't seem impossible that I'm
>> overlooking something), but surely putting insane values here
>> can lead to hard to debug guest crashes.
> 
> I had the same thought (e.g. XSA-111), but all modifications like this
> are already possible with a cunningly-crafted sethvmcontext so we are at
> no more risk than before.

By or for HVM guests. But how about PV?

> Furthermore, I can't think of any plausible validation which could be
> done.  It is entirely possible that this interface could be used to
> bounce execution into a hidden introspection agent.

Flipping VM, AC, NT or altering IOPL would all seem bogus to me.

Jan


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