From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Schmoll Subject: Re: [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface Date: Mon, 27 Mar 2017 15:07:54 +0200 Message-ID: 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 Content-Type: multipart/mixed; boundary="===============1911853880623682704==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csUNz-0003Se-3Q for xen-devel@lists.xenproject.org; Mon, 27 Mar 2017 13:08:39 +0000 Received: by mail-it0-f49.google.com with SMTP id y18so51769167itc.1 for ; Mon, 27 Mar 2017 06:08:36 -0700 (PDT) In-Reply-To: <20170326130435.t6ncmasbn766d6tg@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu Cc: xen-devel@lists.xenproject.org, Felix Ekkehard Schmoll List-Id: xen-devel@lists.xenproject.org --===============1911853880623682704== Content-Type: multipart/alternative; boundary=001a1141d0fa7a4e23054bb60a99 --001a1141d0fa7a4e23054bb60a99 Content-Type: text/plain; charset=UTF-8 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, > > 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. > > > > --001a1141d0fa7a4e23054bb60a99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-26 15:04 GMT+02:00 Wei Liu <wei.liu2@citrix.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 26, 2017 at 01= :33:08PM +0200, Felix Schmoll wrote:
[...]
> > So just one last time to be clear about th= is: You can't just ignore
> interrupts and write all other edges to a shared memory region, like t= he
> 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.=C2=A0 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 a= s
well.=C2=A0 Or, you can make Xen copy that to a userspace buffer. Either wa= y,
you need to make a hypercall.

I think having Xen copy the to a buffer is simpler because=C2=A0 you don= 9;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 wha= t
> 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 suppor= t
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 othe= r
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<= br> 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 --=C2=A0 maybe you're mostly interested in hacking together a working prototype? I think that's acceptable, too.=C2=A0 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.
=C2=A0
Principally= I would be fine with either the tracing or the prototype, I find it howeve= r 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 w= ould be just defined by "does it run".

W= hat I'm having in my mind right now is still a rather vague notion of h= ow the tracing output looks like and an a bunch of ideas on what afl and sy= zkaller do, combined with huge gaps in how Xen "really" works. Th= at will certainly start to clear up once I start really digging into it, bu= t until then I have to rely mostly on your intuition in terms of what is re= alistic in what timeframe.

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

Felix
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
>
> Is there any particular format you're thinking of for the executio= n 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 ha= ve to
> build some infrastructure similar to what syzkaller does to actually r= un
> the hypervisor, i.e. some virtualisation environment to run the hyperv= isor
> in, and so on, right?
>

No. That would be too much work. Some critical pieces are still miss= ing.

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

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

Wei.

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

--001a1141d0fa7a4e23054bb60a99-- --===============1911853880623682704== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1911853880623682704==--