On 30/05/2018 19:30, Natarajan, Janakarajan wrote:
> On 5/30/2018 2:24 AM, Jan Beulich wrote:
>>>>> On 30.05.18 at 01:33, <andrew.coop...@citrix.com> wrote:
>>>> Would this be better suited ?
>>> Almost.
>>>
>>> The purpose of the validate function is to fix an inherent race
>>> condition which occurs with a vmexit.
>>>
>>> After a vmexit, rereading the instruction for emulation is inherently
>>> racy, and a malicious VM could rewrite the instruction stream while the
>>> vmexit is occuring. As a result, we provide a validate function to
>>> check that the instruction decoded matches one which plausibly broke
>>> for
>>> emulation here.
>>>
>>> Therefore, you want a validate function which checks that the
>>> instruction has a memory operand, and that it falls within the 4k
>>> region
>>> which maps the APIC registers.
>> The validate hook is called right after decode, i.e. before operands
>> have
>> been evaluated, so the latter part of what you suggest cannot be done.
>
> So check to see if there is a memory operand. Something along the
> lines of:
>
> bool has_memory_operand(const struct x86_emulate_state *state,
> const struct
> x86_emulate_ctxt *ctxt)
> {
> if ( (state->desc & DstMask) == DstMem )
> return true;
>
> return false;
> }
x86_insn_is_mem_access() or x86_insn_is_mem_write() (depending on
whether we ever need to emulate a read).
Here are several we prepared earlier, and they are sadly more
complicated than you'd imagine.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
