Xen project Mailing List

2017-03-26 15:04 GMT+02:00 Wei Liu <wei.liu2@xxxxxxxxxx>:

On Sun, Mar 26, 2017 at 01:33:08PM +0200, Felix Schmoll wrote:
[...]
> > So just one last time to be clear about this: You can't just ignore
> interrupts and write all other edges to a shared memory region, like the
> KCOV feature the syzkaller uses does,

Yes, you can.

Since you mention that, let's break things down a bit more.

Yes, you need to ignore interrupt and write the execution path to
somewhere. This is one thing.

The other thing is you need to pass that back to userspace. KCOV does
that by inserting the buffer in which the execution path is stored into
the calling process's address space. You can do that for this project as
well. Or, you can make Xen copy that to a userspace buffer. Either way,
you need to make a hypercall.

I think having Xen copy the to a buffer is simpler because you don't
need to worry about plumbing through the kernel. Less work for you.

> but have to find a way to clean the
> execution path from whatever Xen is doing under the hood, which is what
> makes it difficult? Or is it that afl-gcc is actually doing much more than
> inserting that snippet?

It does a bit more than inserting "that snippet". It also provide a
fork-server, which would stop before executing main function. Xen
doesn't support fork, nor has a main function. Having VM-forking support
is a nebulous goal.

You can, of course, modify afl toolchain to suite your need. But I would
avoid doing that because the changes can't be fed back into AFL
upstream, and we're not interested in maintaining a fork of AFL.

Basically I want to do everything properly since day one. By that I mean
everything should be upstreamable.

The major difficulty is to get things into a shape that can be committed
into xen.git. Yes, getting a prototype working might not be too
difficult for you, but our ultimate goal is make upstream Xen able to
run it on a regular basis.

Even though you're asked to work on this one thing, along the way you
might discover other things that need fixing. You code can't break other
bits of Xen, so you need to at least have basic ideas of what is what
and how they fit together. This is going to take time. First thing that
comes to mind is Xen's build system might not fit for the task yet.

There are other factors, too. Like, you need to learn the dynamics of
the community; reviewers may not have the bandwidth to give you quick
feedback. The non-technical side also plays a significant part in the
whole project, too.

And this is just for the first of all three goals. I'm sure there will
be a lot more hidden obstacles along the way because there are so many
moving parts. Over the years I think I've become more and more
conservative in estimating work. :-)

With all that said -- maybe you're mostly interested in hacking
together a working prototype? I think that's acceptable, too. We need
to be on the same page so that we can work out a feasible plan.

Feel free to speak your thought. This project is meant to be beneficial
to both you and the Xen project. I would be quite delighted to hear your
understanding of the project.

Principally I would be fine with either the tracing or the prototype, I find it however much more difficult to imagine what successfully implementing the tracing would look like and how to write a good proposal that goes into specifics. Writing a proof-of-concept/prototype is easier in that regard as success would be just defined by "does it run".

What I'm having in my mind right now is still a rather vague notion of how the tracing output looks like and an a bunch of ideas on what afl and syzkaller do, combined with huge gaps in how Xen "really" works. That will certainly start to clear up once I start really digging into it, but until then I have to rely mostly on your intuition in terms of what is realistic in what timeframe.

Now if I have to decide between the two, I'd still prefer the tracing, since on the one hand being the author of a hypercall seems to be pretty cool, and on the other hand learning the actual contribution process and writing something ready for deployment seems much more valuable.

Felix

>
> Is there any particular format you're thinking of for the execution path,
> i.e. can the three-line snippet be used, or would that already belong to
> #2, and you would want to have something like a sequence of
> left-/right-branch-taken decisions?

No, I don't have preference on the format.

>
> Also, just for my general understanding, one would in the end still have to
> build some infrastructure similar to what syzkaller does to actually run
> the hypervisor, i.e. some virtualisation environment to run the hypervisor
> in, and so on, right?
>

No. That would be too much work. Some critical pieces are still missing.

> Lastly, do you have any suggestions for what would be a good
> midterm-deliverable? Based on the assumption that the answer to my first
> question is affirmative I was thinking of a thorough idea on how the
> hypercall is implemented.
>

Please read above -- we need to be on the same page.

Wei.

> Thanks once again
> Felix
>
> > Wei.
> >

Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface