2013-05-03 14:25:37 +00:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
2017-07-26 17:01:25 +00:00
|
|
|
<!DOCTYPE html>
|
2013-05-03 14:25:37 +00:00
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
2008-04-23 17:08:31 +00:00
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<h1>Bug reporting</h1>
|
|
|
|
|
|
2010-10-23 21:46:32 +00:00
|
|
|
<ul id="toc"></ul>
|
|
|
|
|
|
2017-07-26 14:52:42 +00:00
|
|
|
<h2><a id="security">Security Issues</a></h2>
|
Document security reporting & handling process
Historically security issues in libvirt have been primarily
triaged & fixed by the Red Hat libvirt members & Red Hat
security team, who then usually notify other vendors via
appropriate channels. There have been a number of times
when vendors have not been properly notified ahead of
announcement. It has also disadvantaged community members
who have to backport fixes to releases for which there are
no current libvirt stable branches.
To address this, we want to make the libvirt security process
entirely community focused / driven. To this end I have setup
a new email address "libvirt-security@redhat.com" for end
users to report bugs which have (possible) security implications.
This email addr is backed by an invitation only, private
archive, mailing list. The intent is for the list membership
to comprise a subset of the libvirt core team, along with any
vendor security team engineers who wish to participate in a
responsible disclosure process for libvirt. Members of the
list will be responsible for analysing the problem to determine
if a security issue exists and then issue fixes for all current
official stable branches & git master.
I am proposing the following libvirt core team people as
members of the security team / list (all cc'd):
Daniel Berrange (Red Hat)
Eric Blake (Red Hat)
Jiri Denemar (Red Hat)
Daniel Veillard (Red Hat)
Jim Fehlig (SUSE)
Doug Goldstein (Gentoo)
Guido Günther (Debian)
We don't have anyone from Ubuntu on the libvirt core team.
Serge Hallyn is the most frequent submitter of patches from
Ubuntu in recent history, so I'd like to invite him to join.
Alternatively, Serge, feel free to suggest someone else to
represent Ubuntu's interests.
If any other vendors/distros have security people who are
responsible for dealing with libvirt security issues, and
want to join to get early disclosure of issues, they can
suggest people. Existing security team members will vet /
approve such requests to ensure they are genuine.
Anyone on the team / list will be **required** to honour any
embargo period agreed between members for non-public issues
that are reported. The aim will be to have a maximum 2 week
embargo period in the common case, extendable to 1 month if
there is sufficient justification made. If anyone feels they
are unable to follow such an embargo process for whatever
reason, please decline membership of the security list/team.
The patch which follows puts up some docs on the website
about all of this....
Document how to report security bugs and the process that
will be used for addressing them.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-06-04 10:06:01 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
If you think that an issue with libvirt may have security
|
2015-03-19 15:53:00 +00:00
|
|
|
implications, <strong>please do not</strong> publicly
|
Document security reporting & handling process
Historically security issues in libvirt have been primarily
triaged & fixed by the Red Hat libvirt members & Red Hat
security team, who then usually notify other vendors via
appropriate channels. There have been a number of times
when vendors have not been properly notified ahead of
announcement. It has also disadvantaged community members
who have to backport fixes to releases for which there are
no current libvirt stable branches.
To address this, we want to make the libvirt security process
entirely community focused / driven. To this end I have setup
a new email address "libvirt-security@redhat.com" for end
users to report bugs which have (possible) security implications.
This email addr is backed by an invitation only, private
archive, mailing list. The intent is for the list membership
to comprise a subset of the libvirt core team, along with any
vendor security team engineers who wish to participate in a
responsible disclosure process for libvirt. Members of the
list will be responsible for analysing the problem to determine
if a security issue exists and then issue fixes for all current
official stable branches & git master.
I am proposing the following libvirt core team people as
members of the security team / list (all cc'd):
Daniel Berrange (Red Hat)
Eric Blake (Red Hat)
Jiri Denemar (Red Hat)
Daniel Veillard (Red Hat)
Jim Fehlig (SUSE)
Doug Goldstein (Gentoo)
Guido Günther (Debian)
We don't have anyone from Ubuntu on the libvirt core team.
Serge Hallyn is the most frequent submitter of patches from
Ubuntu in recent history, so I'd like to invite him to join.
Alternatively, Serge, feel free to suggest someone else to
represent Ubuntu's interests.
If any other vendors/distros have security people who are
responsible for dealing with libvirt security issues, and
want to join to get early disclosure of issues, they can
suggest people. Existing security team members will vet /
approve such requests to ensure they are genuine.
Anyone on the team / list will be **required** to honour any
embargo period agreed between members for non-public issues
that are reported. The aim will be to have a maximum 2 week
embargo period in the common case, extendable to 1 month if
there is sufficient justification made. If anyone feels they
are unable to follow such an embargo process for whatever
reason, please decline membership of the security list/team.
The patch which follows puts up some docs on the website
about all of this....
Document how to report security bugs and the process that
will be used for addressing them.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-06-04 10:06:01 +00:00
|
|
|
report it in the bug tracker, mailing lists, or irc. Libvirt
|
|
|
|
|
has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a>
|
|
|
|
|
that should be used instead. So if your issue has security
|
|
|
|
|
implications, ignore the rest of this page and follow the
|
|
|
|
|
<a href="securityprocess.html">security process</a> instead.
|
|
|
|
|
</p>
|
|
|
|
|
|
2020-04-09 13:40:47 +00:00
|
|
|
<h2><a id="bugtracking">Bug Tracking</a></h2>
|
2010-10-23 21:46:32 +00:00
|
|
|
|
2008-04-23 17:08:31 +00:00
|
|
|
<p>
|
2012-02-23 22:49:25 +00:00
|
|
|
If you are using libvirt binaries from a Linux distribution
|
|
|
|
|
check below for distribution specific bug reporting policies
|
|
|
|
|
first.
|
2008-04-23 17:08:31 +00:00
|
|
|
</p>
|
|
|
|
|
|
2017-07-26 14:52:42 +00:00
|
|
|
<h2><a id="general">General libvirt bug reports</a></h2>
|
2008-04-23 17:08:31 +00:00
|
|
|
|
|
|
|
|
<p>
|
2020-04-09 13:40:47 +00:00
|
|
|
Bugs in upstream libvirt code should be reported as issues in the
|
|
|
|
|
appropriate <a href="https://gitlab.com/libvirt">project on GitLab.</a>
|
2012-02-23 22:49:25 +00:00
|
|
|
Before submitting a ticket, check the existing tickets to see if
|
|
|
|
|
the bug/feature is already tracked.
|
2008-04-23 17:08:31 +00:00
|
|
|
</p>
|
2012-02-23 22:49:25 +00:00
|
|
|
<p>
|
|
|
|
|
It's always a good idea to file bug reports, as the process of
|
|
|
|
|
filing the report always makes it easier to describe the
|
|
|
|
|
problem, and the bug number provides a quick way of referring to
|
2020-04-09 13:40:47 +00:00
|
|
|
the problem. However, not everybody in the community pays frequent
|
|
|
|
|
attention to issues, so after you file a bug, asking questions
|
2012-02-23 22:49:25 +00:00
|
|
|
and submitting patches on <a href="contact.html">the libvirt
|
|
|
|
|
mailing lists</a> will increase your bug's visibility and
|
|
|
|
|
encourage people to think about your problem. Don't hesitate to
|
|
|
|
|
ask questions on the list, as others may know of existing
|
|
|
|
|
solutions or be interested in collaborating with you on finding
|
|
|
|
|
a solution. Patches are always appreciated, and it's likely
|
|
|
|
|
that someone else has the same problem you do!
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
If you decide to write code, though, before you begin please
|
|
|
|
|
read the <a href="hacking.html">contributor guidelines</a>,
|
|
|
|
|
especially the first point: "Discuss any large changes on the
|
|
|
|
|
mailing list first. Post patches early and listen to feedback."
|
|
|
|
|
Few development experiences are more discouraging than spending
|
|
|
|
|
a bunch of time writing a patch only to have someone point out a
|
|
|
|
|
better approach on list.
|
|
|
|
|
</p>
|
2008-04-23 17:08:31 +00:00
|
|
|
|
|
|
|
|
<ul>
|
2020-04-09 13:40:47 +00:00
|
|
|
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues">View libvirt.git tickets</a></li>
|
|
|
|
|
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues/new">New libvirt.git ticket</a></li>
|
2008-04-23 17:08:31 +00:00
|
|
|
</ul>
|
|
|
|
|
|
2020-04-09 13:40:47 +00:00
|
|
|
<p>
|
|
|
|
|
Note bugs in language bindings and other sub-projects should be
|
|
|
|
|
reported to their corresponding git repository rather than the
|
|
|
|
|
main libvirt.git linked above.
|
|
|
|
|
</p>
|
|
|
|
|
|
2017-07-26 14:52:42 +00:00
|
|
|
<h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
|
2008-04-23 17:08:31 +00:00
|
|
|
<ul>
|
|
|
|
|
<li>
|
2012-02-23 22:49:25 +00:00
|
|
|
If you are using binaries from <strong>Fedora</strong>, enter
|
|
|
|
|
tickets against the <code>Fedora</code> product and
|
|
|
|
|
the <code>libvirt</code> component.
|
2009-11-06 15:04:19 +00:00
|
|
|
<ul>
|
|
|
|
|
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
|
|
|
|
|
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
|
|
|
|
|
</ul>
|
2008-04-23 17:08:31 +00:00
|
|
|
</li>
|
|
|
|
|
<li>
|
2012-02-23 22:49:25 +00:00
|
|
|
<p>
|
|
|
|
|
If you are using binaries from <strong>Red Hat Enterprise
|
|
|
|
|
Linux</strong>, enter tickets against the Red Hat Enterprise
|
|
|
|
|
Linux product that you're using (e.g., Red Hat Enterprise
|
|
|
|
|
Linux 6) and the <code>libvirt</code> component. Red Hat
|
|
|
|
|
bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
|
|
|
|
|
you are a Red Hat customer.
|
|
|
|
|
</p>
|
2008-04-23 17:08:31 +00:00
|
|
|
</li>
|
|
|
|
|
<li>
|
2012-02-23 22:49:25 +00:00
|
|
|
<p>
|
|
|
|
|
If you are using binaries from another Linux distribution
|
|
|
|
|
first follow their own bug reporting guidelines.
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
Finally, if you are a contributor to another Linux
|
|
|
|
|
distribution and would like to have your procedure for
|
|
|
|
|
filing bugs mentioned here, please mail the libvirt
|
|
|
|
|
development list.
|
|
|
|
|
</p>
|
2008-04-23 17:08:31 +00:00
|
|
|
</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
|
|
|
|
|
2017-07-26 14:52:42 +00:00
|
|
|
<h2><a id="quality">How to file high quality bug reports</a></h2>
|
2008-04-23 17:08:31 +00:00
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
To increase the likelihood of your bug report being addressed it is
|
|
|
|
|
important to provide as much information as possible. When filing
|
|
|
|
|
libvirt bugs use this checklist to see if you are providing enough
|
|
|
|
|
information:
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<ul>
|
2010-01-08 00:40:38 +00:00
|
|
|
<li>The version number of the libvirt build, or SHA1 of the GIT
|
|
|
|
|
commit</li>
|
2008-04-23 17:08:31 +00:00
|
|
|
<li>The hardware architecture being used</li>
|
|
|
|
|
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
|
|
|
|
|
<li>The XML config of the guest domain if relevant</li>
|
2018-03-28 23:51:41 +00:00
|
|
|
<li>For Xen hypervisor, the domain logfiles from /var/log/xen and
|
|
|
|
|
/var/log/libvirt/libxl</li>
|
2008-04-23 17:08:31 +00:00
|
|
|
<li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
|
|
|
|
|
</ul>
|
|
|
|
|
|
2010-11-10 12:16:37 +00:00
|
|
|
<p>
|
|
|
|
|
If the bug leads to a tool linked to libvirt crash, then the best
|
|
|
|
|
is to provide a backtrace along with the scenario used to get the
|
|
|
|
|
crash, the simplest is to run the program under gdb, reproduce the
|
2012-02-23 22:49:25 +00:00
|
|
|
steps leading to the crash and then issue a gdb "bt -a" command to
|
2010-11-10 12:16:37 +00:00
|
|
|
get the stack trace, attach it to the bug. Note that for the
|
2013-10-22 03:02:43 +00:00
|
|
|
data to be really useful libvirt debug information must be present
|
2010-11-10 12:16:37 +00:00
|
|
|
for example by installing libvirt debuginfo package on Fedora or
|
|
|
|
|
Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
|
|
|
|
|
to running gdb.</p>
|
|
|
|
|
<p>
|
2012-02-23 22:49:25 +00:00
|
|
|
It may also happen that the libvirt daemon itself crashes or gets stuck,
|
2010-11-10 12:16:37 +00:00
|
|
|
in the first case run it (as root) under gdb, and reproduce the sequence
|
2012-08-22 18:29:18 +00:00
|
|
|
leading to the crash, similarly to a normal program provide the
|
2010-11-10 12:16:37 +00:00
|
|
|
"bt" backtrace information to where gdb will have stopped.<br/>
|
2012-02-23 22:49:25 +00:00
|
|
|
But if libvirtd gets stuck, for example seems to stop processing
|
2010-11-10 12:16:37 +00:00
|
|
|
commands, try to attach to the faulty daemon and issue a gdb command
|
|
|
|
|
"thread apply all bt" to show all the threads backtraces, as in:</p>
|
|
|
|
|
<pre> # ps -o etime,pid `pgrep libvirt`
|
|
|
|
|
... note the process id from the output
|
|
|
|
|
# gdb /usr/sbin/libvirtd
|
2013-10-22 03:02:43 +00:00
|
|
|
.... some information about gdb and loading debug data
|
2013-11-30 18:27:15 +00:00
|
|
|
(gdb) attach $the_daemon_process_id
|
2010-11-10 12:16:37 +00:00
|
|
|
....
|
|
|
|
|
(gdb) thread apply all bt
|
2013-10-22 03:02:43 +00:00
|
|
|
.... information to attach to the bug
|
2010-11-10 12:16:37 +00:00
|
|
|
(gdb)
|
|
|
|
|
</pre>
|
|
|
|
|
|
2008-04-23 17:08:31 +00:00
|
|
|
</body>
|
|
|
|
|
</html>
|
