Re: [Xen-devel] [RFC] Proposal: Fuzzing the Hypervisor - Tracing

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, May 23, 2017 at 11:32:52AM +0200, Felix Schmoll wrote:
> Hi,
> 
> I'm Felix Schmoll, one of the GSoC students this year. Go Xen!
> 
[...]
> 
> ==================================
> 2.1.1 Function content
> ==================================
> The "struct domain" as defined in xen/include/xen/sched.h should be
> extended to include:
>     * a pointer to the trace buffer (NULL if domain is not traced)
>     * the next position to write to in the trace buffer
>     * size of the trace buffer
> 
> An alternative considered here was to have some sort of global array to
> store the data relevant for tracing in, but this limits the number of
> domains.
> 

Yes. Using a per-domain buffer is better. You can even allocate /
deallocate on the fly to save memory.

> Pseudo code:
> 
> /* Check if the current domain is being traced and, if appropriate, write
> the program counter to the buffer. */
> if(domain is traced && buffer not full) {
>     current_domain->trace_buffer[current_domain->trace_buffer_pos++] =
>        __builtin_return_address(0)
> }

Have you thought about multiple-vcpu guests? I think this only works
with one vcpu guest? That's fine IMO, but it is a limitation worth
spelling out.

> 
> ==================================
> 2.2 Hypercall-Interface
> ==================================
> As stated in the preceding sections, a hypercall is needed to extract the
> execution path. The proposed interface is the following:
> 
> /*
> * @brief Traces the execution path of hypercalls executed by a domain.
> * @param domain_id Domain whose execution path is supposed to be traced
> * @param buffer Buffer to write program counters to
> * @param size Size of the buffer
> * @param mode, if to trace or to stop tracing
> * @return Success or error in some form (e.g. number of PC’s written for
> success)
> */
> int trace_execution(int domain_id, int* buffer, int size, int mode);
> 
> This interface together with the previous snippet content seem to imply
> that some program counters of this hypercall might be included in the
> buffer (there will be edges between setting the buffer and returning to the
> kernel if a domain traces itself). For the purpose of fuzzing this doesn't
> matter as long as this is the same for all runs.
> 

This looks OK. A more conventional way is to mimic other domctl and
sysctl calls. You pack the arguments of different modes into an union
and then pass the struct to hypervisor.

Also if this is the declaration of hypercall function, it looks wrong.
There is strict distinction between userspace pointers and hypervisor
pointers. Some macros are needed to make this correct. Again, check out
hypervisor code.

> ==================================
> 2.3 Adjustments to libxc
> ==================================
> With this interface the only modification to libxc would be to add the new
> hypercall.
> 
> An alternative considered was to implement an event notification system
> which informs the trace hypercall when a hypercall starts and ends. One
> could then change the interface to just trace the next hypercall instead of
> tracing all hypercalls. This however involves changing the xencall
> functions and throws up some questions in regards to having multiple
> hypercalls at the same time. As long as the hypercall is used only for
> fuzzing a single hypercall at a time the difference should be irrelevant.
> 

Use the simple approach please. There is no need to make things more
complex than necessary.

Furthermore, we don't want to limit our system to hypercall only. There
are other interfaces that we want to fuzz.

> ==================================
> 2.4 Build
> ==================================
> Inserting even a single instruction at every edge is a rather costly
> operation in case the feature is never intended to be used. The tracing
> should thus be an optional build-feature that has to be explicitly enabled.
> 

Yes. Check out Kconfig. Introduce a CONFIG_TRACE_PC or something.

Overall this proposal looks promising. We have a lot of flexibility in
this regard because this system is not meant to be used in a production
environment so we can change the interface at will.

The Xen community operates based on lazy consensus. If you don't get any
more feedback by the time coding period starts, you should start coding.

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