On 03/16/2017 09:08 AM, D L wrote:
On Tue, Mar 7, 2017 at 4:08 AM, Michal Privoznik <mprivozn@xxxxxxxxxx>
wrote:
The file has to be stored locally. Libvirt doesn't have an
'url-grabber'. In fact, our APIs expect XML document passed as string
(not a filename where it is stored). It's just virsh that allows users
to point it to a file which is read and passed to the define API.
Oh, my bad. The typing was somehow translated into an url in my browser.
But it is an interesting idea to have config files requested via http.
I'm not so sure. This looks like something for tools working on the top
of libvirt, e.g. virt-install. If we were to have everything in libvirt,
it would become unmanageable.
I took a deeper look at the domain_conf.c and network_conf.c. It is just so
amazing to see a single file having 26 K lines of code. I first thought it
must
be generated automatically, then I found there are ~1640 commit for that
single file over 8 years.
Yes, ctags is very very helpful!
Yeah, it is our biggest file. The next one is src/qemu/qemu_driver.c.
But ctags are useful not because of big files, but because our code is
scattered into a lot of files. But that's not important now.
Now that we have parsed the domain XML into internal representation
(virDomainDef), we can look into qemu command line generation. I think
the whole process is best visible in qemuDomainCreateXML() (e.g. "vim -t
qemuDomainCreateXML" ;-)). This is qemu driver implementation of public
API virDomainCreateXML(). It allows users to create so called transient
domains. Long story short: "here, I have domain XML, start it up for me,
will you?". Therefore at the beginning the domain XML is parsed (using
the function described above), several not-important-right-now functions
are called and then qemuProcessStart() is called which calls
qemuProcessLaunch() which calls qemuBuildCommandLine(). Finally, this is
the function that takes the virDomainDef (among other arguments) and
produces yet another internal representation of qemu command line
(virCommandPtr). This command line is then executed later in the process.
Here I traced through the invocations starting from qemuDomainCreateXML.
Indeed, eventually, it returned a _virCommand struct with some process
information, like file descriptors, pid, uid, gid etc. And for different
purposes,
it is being passed as an argument in about 200 places, such as
in ./src/qemu/qemu_command.c, there are
qemuBuildMasterKeyCommandLine(), and
qemuBuildNVRAMCommandLine(),
The virCommand type is for generic command execution. Not just qemu. For
instance, when creating new storage volumes, libvirt spawns qemu-img
tool. That's why you can find some virCommand occurrences all over the
place (e.g. in storage_util.c).
Moreover, some functions take existing virCommand object and just add
something to it - just like qemuBuildMasterKeyCommandLine() is doing.
This way, the build process of command line is split into many
functions. The main reason to do so is better maintainability. Just like
you'd use functions in regular code to semantically divide code into parts.
What's important here is qemuBuildCommandLine() which takes domain
definition (well, pointer to it), and constructs correspoding qemu
command line (represented as a pointer to virCommand which is returned)
by calling several functions - each one constructing some part of the
command line.
Now the GSoC idea could be to test this qemuBuildCommandLine() function.
A fuzzer would create the virDomainDef object, we would run
qemuBuildCommandLine() over it and see if it crashed or not, whether a
sane output was generated or not.
Then to take this one level up, virDomainDef is produced by
virDomainDefParse() which takes a string (read XML document) and parses
it. At this point, the fuzzer does not need to care about virDomainDef
at all, it can just create all possible XML documents and call
virDomainDefParse() over them, and then qemuBuildCommandLine() over the
result of parser. Therefore I think this is what we should aim at.
in /src/util/vircommand.c: there are
virCommandSetWorkingDirectory(), and
virCommandProcessIO()
in /src/rpc/virnetsocket.c, there is
virNetSocketNewConnectCommand().
in /src/storage/storage_util.c, there is
storageBackendCreateQemuImgSetOptions(). etc
3. And libvirt also is compiled with libxml2.
Yes. This has strong historical background (hint: look who started
libvirt and who wrote libxml2 ;-)). Frankly, I don't think we've ever
considered a different xml parsing library.
Oh yeah, just for curiosity, I git cloned libxml2, and find the name of
Daniel
Veillard, then found out more stories. Really amazing work.
Yeah. Daniel wrote libxml2 and then started libvirt. So choosing XML was
a nobrainer :-).
Maybe I should not ask, (but since I know nothing yet, it won't hurt), have
we
ever considered another format alternative to xml? Json, for example, since
xml is kind of hard to parse.
It's not any harder than JSON. There's 1:1 mapping between JSON and XML.
Anything that can be expressed in one format can be expressed in the
other too. And we cannot really switch formats because we try to stay
backward compatible. Meaning, if you write a program that co-operates
with libvirt, any subsequent update of libvirt should not break your
application. Therefore, if your application knows how to create/parse
XML documents (because that's what you need currently if you talk to
libvirt), we cannot switch to JSON, because your application would stop
working with XML parser error.
Just a side note - there are plenty projects on the top of libvirt which
create/parse the XML for you so you don't even have to touch XML
yourself. You don't even know that there's XML behind the scenes. One of
such projects is libvirt-gobject, for instance. So XML is not an issue here.
By the way, when I save a VM's state with "virsh save ID FILE_NAME", it
generated
a huge XML file (500 M to 16G)
Yes, becuase the file does not only contain the domain XML, but also
insternal state of the domain (=guest memory + qemu memory). Therefore,
if you restore from it, you will get the very same state as when doing
the save.
then I found out virDomainSnapshotCreateXML()
is called when executing that command (
https://libvirt.org/formatsnapshot.html).
When restoring the state, it is calling virDomainRevertToSnapshot(),
virDomainSnapshotGetXMLDesc etc.
Not really. 'virsh save' calls virDomainSave() which calls
qemuDomainSave() (because conn->driver points to qemuHypervisorDriver).
qemuDomainSave() -> qemuDomainSaveFlags() -> qemuDomainSaveInternal() ->
qemuDomainSaveMemory() where basically all the interesting work takes place.
For the XML fuzzing project, do we need
to consider those situations?
I think the most important is to have XML -> qemu cmd line fuzzing in
place and only after that focus on extending that to what I'm describing
below in previous e-mails.
4. Then in virt-xml-validate, which is a bash script,
(in build/bin directory after make install) calling xmllint.
Yeah. Writing our XMLs by hand can be overwhelming. Moreover, libvirt
has this philosophy of ignoring unknown elements/attributes. So it might
happen that for instance you have a typo in an element name and you're
still wondering why libvirt ignores that particular setting (e.g. path
to disk of domain). Therefore we have grammar rules (RNG) that could
help you here - virt-xml-validate would error out in this example. Well,
even virsh errors our now because it instructs libvirt to do the XML
validation before parsing. But that hasn't been always the case.
I have not been able to get round to figure out the relations of the
above
pieces yet.
I spent some time to try to instrument and compile the executables with
AFL, but so
far with no luck. (The idea is as simple as changing gcc in
Makefile/configure to afl-gcc).
The attached figure is just a demo showing using AFL to fuzz virt-admin,
which is
not instrumented, (so kinda of boring and not quite useful). But I think
AFL could be
one of the candidate as a fuzzer for this project due its prevalence and
proved effectiveness.
We don't have to limit ourselves just for domain XML -> qemu cmd line
fuzzing. We can look into other areas too (there's a lot of inputs for
libvirt), e.g. RPC protocol (we have our own protocol for communication
with distant server/client over network), fuzz XML parsers themselves
(domain is not the only object that libvirt manages, we have networks,
interfaces, storage pools/volumes, etc.). It's just that qemu cmd line
fuzzing seemed complicated enough so that the chances of running a
fuzzer successfully are high.
All right. I think that's definitely a good idea. I will start looking
into this
tomorrow and resume the fuzzing experiment that I left.
Thank you very much for the detailed explanation. I am having a
much better understanding about the scope and how I would plan to
confine/manage the timeline of the project.
Cheers.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
