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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Mon, Sep 12, 2016 at 10:02 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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)?

No, right now it's only allowed in response to an INT3 event as that's
really the only case where I see this being needed. We could extend
it's scope so we can trigger it in response to any kind of vm_event,
but right now I don't see that being necessary.

>
>>> 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.

Ah, good point. With LibVMI we already handle reading a buffer with VA
addressing even if the PA layout crosses page boundaries, so it's
going to be simpler and safer to have the client return a full buffer
as you suggested.

Thanks,
Tamas

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