Bug 876828 - the qcow2 disk's major:minor number still exists in guest's devices.list after hot-unplug
the qcow2 disk's major:minor number still exists in guest's devices.list afte...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Eric Blake
Virtualization Bugs
: Regression
Depends On:
Blocks: 886216
  Show dependency treegraph
 
Reported: 2012-11-14 23:53 EST by Ming Tian
Modified: 2013-02-21 02:26 EST (History)
11 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-11.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 02:26:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ming Tian 2012-11-14 23:53:39 EST
Description of problem:
the qcow2 disk's major:minor number still exists in guest's devices.list after hot-unplug

Version-Release number of selected component (if applicable):
libvirt-0.10.2-8.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. install a guest using virsh, virt-install or virt-manager

2. get host disk infomation (such as /dev/sda)
# df -h

3. create a qcow2 format image and let it point at /dev/sda
# qemu-img create -f qcow2 /var/lib/libvirt/images/foo.qcow2 -o backing_file=/dev/sda

4. check whether demo.qcow2 disk pointing at /dev/sda and disk format is qcow2
# qemu-img info /var/lib/libvirt/images/foo.qcow2

5. editor the following xml block to foo.xml
# cat foo.xml
 <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/foo.qcow2'/>
      <target dev='vdb' bus='virtio'/>
 </disk>

6. get the above disk /dev/sda major:minor number 
#ls -la /dev/sda

7. check whether the above major:minor(8:0) number exists in devices.list
# grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list

8. attach the above foo.xml to the guest
# virsh attach-device demo foo.xml

9. check whether the above major:minor(8:0) number exists in devices.list
# grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list

10. detach foo.xml from the guest
# virsh detach-device demo foo.xml

11. check whether the above major:minor(8:0) number exists in devices.list
# grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list

Actual results:
b 8:0 rw

Expected results:
no results

Additional info:
This works on libvirt-0.9.10-21.el6.x86_64.rpm, so it's a regression bug.
Comment 1 Ming Tian 2012-11-14 23:54:43 EST
Since it  works on libvirt-0.9.10-21.el6.x86_64.rpm, so it's a regression bug.
Comment 4 Alex Jia 2012-11-15 00:35:18 EST
Daniel, although I can reproduce this question on libvirt-0.10.2-8 and it's okay on libvirt RHEL6.3 release version(libvirt-0.9.10-21), I still want to confirm if it's a regression bug with you, thanks.

Alex
Comment 5 Eric Blake 2012-11-15 07:16:36 EST
Failure to revoke cgroup device ACLs on hotplug does sound like a regression; thankfully it is not a security issue (once access has been granted, failure to revoke cgroup ACLs merely means that a compromised qemu can continue to open() the device; but if qemu already has an fd to the device, it doesn't need to open() the device, so there is no escalation in what a compromised qemu can already do).  I have not yet looked in the code to see what may have caused the regression, or how easy it would be to plug.
Comment 6 Alex Jia 2012-11-15 22:05:20 EST
(In reply to comment #5)
> Failure to revoke cgroup device ACLs on hotplug does sound like a
> regression; thankfully it is not a security issue (once access has been
> granted, failure to revoke cgroup ACLs merely means that a compromised qemu
> can continue to open() the device; but if qemu already has an fd to the
> device, it doesn't need to open() the device, so there is no escalation in
> what a compromised qemu can already do).  I have not yet looked in the code
> to see what may have caused the regression, or how easy it would be to plug.

Eric, thanks for your comments.
Comment 8 Eric Blake 2012-11-26 19:30:23 EST
I've confirmed the regression in my testing; it looks like the hot unplug code is failing to populate the new disk->backingChain element (or better, reusing the existing disk->backingChain that was created during hot plug).  I expect to have a fix in the next 24 hours.
Comment 9 Eric Blake 2012-11-27 09:05:36 EST
Upstream patch proposed:
https://www.redhat.com/archives/libvir-list/2012-November/msg01150.html
Comment 11 Eric Blake 2012-11-29 16:37:47 EST
Actually, this requires two patches (both qemuDomainDetachDiskDevice and qemuDomainDetachPciDiskDevice share the same copy-and-paste sequence).
Comment 14 zhpeng 2012-12-06 02:57:05 EST
# ll /dev/sda
brw-rw----. 1 qemu qemu 8, 0 Dec  6 12:18 /dev/sda

#  virsh attach-device 8 foo.xml
Device attached successfully
# cat  /cgroup/devices/libvirt/qemu/vr-rhel6u2-x86_64-kvm/devices.list 
...
b 8:0 rw

#  virsh detach-device 8 foo.xml
Device detached successfully

cat  /cgroup/devices/libvirt/qemu/vr-rhel6u2-x86_64-kvm/devices.list 
...




So it's verified.

pkgs:
libvirt-0.10.2-11.el6.x86_64
Comment 15 errata-xmlrpc 2013-02-21 02:26:42 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html

Note You need to log in before you can comment on or make changes to this bug.