Bug 520864 - libvirt is using untrusted 'info vcpus' PID data for already running VM after libvirtd restart
libvirt is using untrusted 'info vcpus' PID data for already running VM after...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
 
Reported: 2009-09-02 14:00 EDT by Daniel Berrange
Modified: 2009-09-15 06:47 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-15 06:25:32 EDT
Type: ---
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 Daniel Berrange 2009-09-02 14:00:15 EDT
Description of problem:
Once the guest has started executing, libvirt must be careful about trusting data from the QEMU monitor. During initial VM startup it is safe to trust data up until 'cont' has been issued to start the vCPUs.

After a libvirtd restart though, the QEMU driver is calling 'info vcpus' to get the vCPU<->thread PID  mapping data. It should not do this. THis data should be stored in the persistent state file during initial VM startup, and never queried thereafter.

Version-Release number of selected component (if applicable):
0.7.0

How reproducible:
N/a

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 Mark McLoughlin 2009-09-15 06:25:32 EDT
* Mon Sep 14 2009 Mark McLoughlin <markmc@redhat.com> - 0.7.1-0.2.gitfac3f4c
- Update to newer snapshot of 0.7.1
- Stop libvirt using untrusted 'info vcpus' PID data (#520864)
- Support relabelling of USB and PCI devices
- Enable multipath storage support
- Restart libvirtd upon RPM upgrade

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