Re: [Xen-devel] [RFC] x86/vm_event: Allow returning i-cache for emulation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.09.16 at 17:48, <tamas.lengyel@xxxxxxxxxxxx> wrote:
> On Mon, Sep 12, 2016 at 8:56 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 09.09.16 at 17:41, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> > @@ -1783,7 +1786,14 @@ static int _hvm_emulate_one(struct
>> hvm_emulate_ctxt *hvmemul_ctxt,
>> >          pfec |= PFEC_user_mode;
>> >
>> >      hvmemul_ctxt->insn_buf_eip = regs->eip;
>> > -    if ( !vio->mmio_insn_bytes )
>> > +
>> > +    if ( unlikely(hvmemul_ctxt->set_context_insn) )
>> > +    {
>> > +        memcpy(hvmemul_ctxt->insn_buf, curr->arch.vm_event->emul_
>> data.data,
>> > +               curr->arch.vm_event->emul_data.size);
>> > +        hvmemul_ctxt->insn_buf_bytes = curr->arch.vm_event->emul_
>> data.size;
>> > +    }
>> > +    else if ( !vio->mmio_insn_bytes )
>>
>> I'm not sure about this ordering: Do you really mean to allow an
>> external entity to override insn bytes e.g. in an MMIO retry, i.e.
>> allowing the retried insn to be different from the original one?
>>
> 
> I'm not sure but there shouldn't be INT3's coming from MMIO, right? So we
> would not have a response-opportunity to override it.

Can't you modify insns at any time from the monitoring app? If
so, wouldn't there be a chance for things to change between
the original insn invocation and the retry (after qemu completed
the request to it)?

>> And additionally I think you need to deal with the case of the
>> supplied data not being a full insn. There shouldn't be any
>> fetching from guest memory in that case imo, emulation should
>> just fail.
>>
> 
> So the idea was to allow partial "masking" of the i-cache. For example, if
> all I want to hide is the 0xCC then it's enough to return 1 byte in
> vm_event, the rest can be (and already is) grabbed from  memory.

Oh, interesting. That makes it even more problematic, imo. Can you
ensure that your patching any whatever the guest may do to its own
insn stream actually remains consistent, even in situations like the
insn crossing a page boundary? IOW what you suggest seems pretty
fragile to me, but would in any case need spelling out very clearly.

Jan


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