From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface Date: Tue, 28 Mar 2017 10:21:14 +0100 Message-ID: <9F9E8099-DD6C-4CCA-BF4E-29759006C0C2@gmail.com> References: <20170321161324.hmsnybth3ktjbzpk@citrix.com> <20170321161442.tpjjtecv6qmsgmev@citrix.com> <20170322085258.s6wcyqgz5vgomsja@citrix.com> <20170322112107.2tkxz6b3kd5emwjf@citrix.com> <20170324125608.imozb5dt42sbhkgz@citrix.com> <20170326130435.t6ncmasbn766d6tg@citrix.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/mixed; boundary="===============6710724116312168180==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csnJX-0002sv-Bb for xen-devel@lists.xenproject.org; Tue, 28 Mar 2017 09:21:19 +0000 Received: by mail-wr0-f193.google.com with SMTP id u1so20808745wra.3 for ; Tue, 28 Mar 2017 02:21:17 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Felix Schmoll Cc: xen-devel@lists.xenproject.org, Wei Liu List-Id: xen-devel@lists.xenproject.org --===============6710724116312168180== Content-Type: multipart/alternative; boundary="Apple-Mail=_44F22A96-B448-4255-8334-E9FFB36AC337" --Apple-Mail=_44F22A96-B448-4255-8334-E9FFB36AC337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > 2017-03-26 15:04 GMT+02:00 Wei Liu >: > 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, >=20 > Yes, you can. >=20 > Since you mention that, let's break things down a bit more. >=20 > [snip] >=20 > 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. > =20 > 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.=20 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.=20 > 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= --Apple-Mail=_44F22A96-B448-4255-8334-E9FFB36AC337 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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>:
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
= --Apple-Mail=_44F22A96-B448-4255-8334-E9FFB36AC337-- --===============6710724116312168180== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6710724116312168180==--