Re: [Xen-devel] [PATCH 0/3] xen: add support for skipping the current instruction

[Mihai DonÈu <mdontu@xxxxxxxxxxxxxxx>]

On Tuesday 09 September 2014 10:47:43 Jan Beulich wrote:
> >>> On 09.09.14 at 04:22, <mdontu@xxxxxxxxxxxxxxx> wrote:
> > RÄzvan Cojocaru has posted a patch in July that added support for
> > computing the length of the instruction that generated the VMEXIT:
> > 
> > http://lists.xen.org/archives/html/xen-devel/2014-07/msg00314.html 
> > 
> > which he then split into two in order to give himself more time to
> > think about Andrew's proposal to extend the existent x86 emulator. I
> > offered to take that off his hands as he was already working to get
> > several patches in.
> > 
> > The initial code was an almost verbatim copy from Linux, with a very
> > small change to make it compile within xen (replaced 'asm/string.h'
> > with 'xen/string.h').
> > 
> > I spent some time to determine what the code save would be if we were
> > to make use of existent xen functionality and my first impression is
> > that the increase in complexity of an already very complex machinery
> > (caused by both the nature of the architecture and by the design of the
> > emulator itself) would not make it worthwhile.
> > 
> > The starting point would be x86_emulate() which uses a carefully coded
> > switch() to walk through the opcode groups, but it only covers a subset
> > of those and, obviously, expects one to add not just instruction length
> > calculation (ie. next eip/rip) but also _actual_ emulation to which I
> > don't think anyone can commit given the architecture complexity (think
> > MMX, SSEn, AVXn etc). The opportunity for bugs makes this task rather
> > prohibitive.
> 
> I disagree, for two reasons: First, there's no reason to implement full
> emulation for everything as long as there's a way for the caller to
> know whether actual emulation (rather than just instruction boundary
> determination) did happen. And second, as recently also pointed out
> by Andrew, making full emulation (including very recent additions like
> AVX-512) a goal would likely be of more than just theoretical value
> (allowing emergency migration of guests to less capable hosts without
> prior CPU feature leveling). Plus - as long as those newer extensions
> could be emulated in ways similar by how the FPU instructions get
> dealt with, I think the scope for bugs can be meaningfully reduced.

I'm looking at emulate_fpu_insn(). Took me a bit to understand the
trick behind it: it doesn't do full emulation just advances the %rip.
Mmm.

> > Masami Hiramatsu, the author of the Linux code, most likely came to the
> > same realization and used a rather simple approach: created
> > x86-opcode-map.txt in which he simply lists the opcode classes in a
> > fairly human readable way. Then he uses an awk script to generate the
> > core of the machinery to which he added a couple of helper functions. I
> > decided to keep this part and see if I can replace some of the helpers,
> > but aside insn_fetch_bytes() which relies on previous calculations made
> > in x86_emulate(), I wasn't able to identify any other code-reuse
> > opportunities. Also, I don't yet have the courage to shuffle code
> > around in x86_emulate.c. :-)
> > 
> > In conclusion, I would opt to bring Masami's code in with very little
> > changes possible (other than coding style which can be handled by a
> > script) so that future updates can be easily ported to xen.
> > 
> > What follows are three patches:
> >   1. adds Masami's et al code (insn_get_length());
> >   2. adds a user in emulate.c;
> >   3. a clang-format script that can be used to do the bulk of the
> >   coding style work on the imported files (should someone else other
> >   than me were to do it).
> > 
> > The motivation behind the 'instruction skipping' idea is to allow
> > memory introspection technologies to instruct Xen to jump over
> > instructions that reside in memory areas of the guest that are marked
> > as NX in EPT (eg. heap/stack of user processes). In such situations,
> > maintaining the vCPU register state is not needed and, as a bonus,
> > expedites the termination of the in-guest process that attempted to
> > execute the code.
> 
> Leaving open why terminating the in-guest process requires advancing
> its IP then, if all other register updates are unnecessary. A huge chunk
> of source code like this needs - I think - a little more of a rationale than
> some exotic, only partially explained use case.

Essentially, instruction skipping is an alternative to
'emulate-no-write'. All it offers is a speed boost, which is noticeable
when, for example, the emulator is walking a piece of code located into
an NX-marked memory area (stack, for example). With emulation, it takes
a long time for an application which has been exploited to terminate
(some types of malware try in a forever-loop to write to the memory
areas they target).

Now, given the tight schedule for 4.5 feature merges of which both
you and Ian talked, I think I'm going to hold this patch for now. It is
not an essential part of memory introspection, but rather an
improvement and it can wait a bit longer.

Thanks,

-- 
Mihai DonÈu

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