From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH V3 2/2] xen: Introduce
	VM_EVENT_FLAG_SET_REGISTERS
Date: Mon, 28 Sep 2015 16:57:19 +0100
Message-ID: <5609635F.3020809@citrix.com>
References: <1443435382-3817-1-git-send-email-rcojocaru@bitdefender.com>
	<1443435382-3817-3-git-send-email-rcojocaru@bitdefender.com>
	<560977FE02000078000A6484@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <560977FE02000078000A6484@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: tamas@tklengyel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, stefano.stabellini@eu.citrix.co, stefano.stabellini@citrix.com, keir@xen.org
List-Id: xen-devel@lists.xenproject.org

On 28/09/15 16:25, Jan Beulich wrote:
>>>> On 28.09.15 at 12:16, <rcojocaru@bitdefender.com> 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.

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.

~Andrew