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

[Lars Kurth <lars.kurth.xen@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2787 bytes --]

Hi all,

I wanted to add a few thoughts here, as this is clearly one of the harder tasks.

> On 27 Mar 2017, at 14:07, Felix Schmoll <eggi.innovations@gmail.com> wrote:
> 
> 2017-03-26 15:04 GMT+02:00 Wei Liu <wei.liu2@citrix.com <mailto:wei.liu2@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.
> 
> [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.

> 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. 

> 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 ).

Hope that helped

Regards
Lars

[-- Attachment #1.2: Type: text/html, Size: 7321 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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