Xen project Mailing List

2017-03-28 13:54 GMT+02:00 Wei Liu <wei.liu2@xxxxxxxxxx>:

On Tue, Mar 28, 2017 at 10:21:14AM +0100, Lars Kurth wrote:
> Hi all,
>
> I wanted to add a few thoughts here, as this is clearly one of the harder tasks.

It's really hard. I don't even expect an experienced Xen developer to be
able to finish all three goals in three months.

Felix, don't feel frustrated if you don't have everything figured out
because even I have not had everything figured out. ;-)

>
> > On 27 Mar 2017, at 14:07, Felix Schmoll <eggi.innovations@xxxxxxxxx> wrote:
> >
> > 2017-03-26 15:04 GMT+02:00 Wei Liu <wei.liu2@xxxxxxxxxx <mailto: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.
> >
> > [snip]
> >
> > 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".
>
> I think there may be other possibilities to structure a proposal, e.g.
> a prototype (or set of experiments) followed by a design and/or gap
> analysis that could be community reviewed (and checked into our docs
> tree). We could also build in a blog post (or similar). The challenge
> is to come up with a structure that ensures that we make progress on
> understanding the problem space and that you have something to show
> and refer to at the end of the project.
>
> I am just throwing this in as a possibility, but obviously Wei would
> have to agree with it.
>

Yes, that's doable.

I don't think we need to necessarily narrow down the deliverables to
"code" or "patch". I agree having some incomplete code and a doc in the
end is acceptable to me.

I think up to this point we have clear understanding of at least one of
the components (the tracing bit). That could be the first level
deliverable. The component to bridge the fuzzer and the hypervisor is
not yet clear, but I think a prototype for that is possible.

> > 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.
>
> I would maybe suggest that you and Wei have a discussion on IRC to
> discuss the pro's and con's of the two different approaches and to see
> what is realistic.
>

Yes. That would be good.

I'm free every afternoon this week (German time, I suppose you're in Europe), so just let me know at least three hours in advance when you're free

to have a chat.

Felix

> > 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.
>
> It is also worth noting that the contribution process for a design or
> similar would be the same than for code (we tend to store such
> documents in [xen.git] / docs ).
>

Correct.

Wei.

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