2017-03-26 15:04 GMT+02:00 Wei Liu <wei.l...@citrix.com>: > 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. > > > >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
