Re: backdoor [Was: Re: [Qemu-devel] [PATCH 00/17] [RFC] static instrumentation]

[Blue Swirl]

On Mon, Oct 25, 2010 at 10:54 AM, Lluís <address@hidden> wrote:
> Blue Swirl writes:
>
>> On Fri, Oct 22, 2010 at 6:32 PM, Lluís <address@hidden> wrote:
>>> Lluís Vilanova (17):
>>>  backdoor: Declare host-side backdoor helpers
>>>  backdoor: [all] Include backdoor helper declarations
>>>  backdoor: Declare guest-side interface macros
>>>  backdoor: [i386] Decode backdoor instructions
>>>  backdoor: [i386] Declare guest-side interface macros
>>>  backdoor: Add a simple example
>
>> The backdoor instruction is problematic. For example, handling that in
>> KVM may be difficult
>
> I thought about implementing guest-directed KVM control, such that the
> guest will be able to enable/disable KVM at will, but I'm not sure how
> this can be accomplished in a generic way (i.e., x86 has vmcall/vmmcall
> as you told me a lot of time ago).
>
>
>> and there are guest visible side effects.
>
> I don't understand what you mean with guest-visible effects.

The guest can examine itself and determine that it has been modified.
Also, the guest needs to be recompiled and adding the extra
instructions changes the memory layout etc. Furthermore, the source
code needs to be available for recompilation.

>> The same effect can be achieved with a MMIO/PIO device or instrumented
>> breakpoints/watchpoints.
>
>> For the MMIO/PIO device solution, there are several PV devices
>> available, for example virtio devices and fw_cfg. Instead of a
>> backdoor instruction, the guest should simply issue MMIO or PIO using
>> regular instructions. For Linux user, a new syscall can be added.
>> Anyway, the guest still needs to be modified.
>
>> Instrumenting GDB watchpoint and/or breakpoint support would be more
>> attractive because this would be completely invisible to the guest and
>> it may be controlled from GDB.
>
> Ok, so far I see different approaches available:
>
> * MMIO/PIO device
>  Needs no undocumented extensions to the ISA, but requires modifying
>  the guest OS (adding a device driver).

Also the guest application needs to be modified.

> * New syscall
>  Needs no undocumented extensions to the ISA, but will only work with
>  *-user emulation.
>
> * watchpoint/breapoint
>  Needs no undocumented extensions to the ISA, but will only work with
>  softmmu emulation, and only as long as the backdoor channel requires
>  no arguments.

We have GDB support also for user emulators. The arguments could be
set up by GDB monitor command.

> * ISA extensions
>  Needs a per-target decoding of the instruction and won't work when
>  running under KVM.
>
> What I used until now (with my old bochs-based implementation), is the
> presented ISA extensions, which are used through library interposition
> (e.g., in softmmu emulation, launch the application with a library in
> LD_PRELOAD that enables/disables simulation using a
> constructor/destructor attribute, plus some extra backdoor communication
> to simulate specific processes by interposing on the fork/clone
> syscall).
>
> My requirements here are:
>
> * Backdoor channels need to provide arguments.
> * It's better to provide the same mechanism for both *-user and softmmu
>  (otherwise the application to simulate or the interposed librariy
>  should be compiled differently on every case).
> * Some applications are not fully simulated, but just some pre-defined
>  loops are, such that I would run the application (on KVM mode if
>  possible) until the interesting loop starts executing, switch to
>  simulation mode, simulate an arbitrary number of loops, switch back to
>  non-simulated mode, run until another specific loop or iteration is
>  reached, repeat the process again.
>  This obviously requires some application modification to insert the
>  communication points, unless these can be identified using symbol
>  interposition (e.g., calls to the OpenMP runtime to simulate certain
>  parallel loops).
>
> The instrumented watchpoint/breakpoint sounds as an interesting
> approach, but I don't see how I can:
>
> * Differentiate among instrumented and non-instrumented
>  watchpoints/breakpoints

Make the instrumentation selectable for each watchpoint/breakpoint.

> * Pass arguments to the instrumentation backend

Together with the breakpoint structure in CPUState, there should be an
extra storage for the arguments (and a flag whether to enable
instrumentation or not) . This could be set up by monitor commands.