mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
XEN_DOMCTL_gdbsx_domstatus is already safe. It loops at most over every vcpu in a domain and breaks at the first vcpu with an event pending, marking it as not-pending. XEN_DOMCTL_gdbsx_pausevcpu had an incorrect bounds check against the vcpu id, allowing an overflow of d->vcpu[] with an id between d->max_vcpus and MAX_VIRT_CPUS. It was also able to overflow a vcpus pause count by many repeated hypercalls. The bounds check is fixed, and vcpu_pause() has been replaced with vcpu_pause_by_systemcontroller() which cuts out at 255 uses. XEN_DOMCTL_gdbsx_unpausevcpu suffered from the same bounds problems as its pause counterpart, and is fixed in exactly the same way. Despite the atomic_read(&v->pause_count), this code didn't successfully prevent against an underflow of the vcpu pause count. The vcpu_unpause() has been replaced with vcpu_pause_by_systemcontroller() which correctly prevents against underflow. The printk() is updated to have a proper guest logging level, and provide more useful information in the XSM case of one domain having debugger privileges over another. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Tim Deegan <tim@xen.org> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen-bugtool =========== The xen-bugtool command line application will collate the Xen dmesg output, details of the hardware configuration of your machine, information about the build of Xen that you are using, plus, if you allow it, various logs. The information collated can either be posted to a Xen Bugzilla bug (this bug must already exist in the system, and you must be a registered user there), or it can be saved as a .tar.bz2 for sending or archiving. The collated logs may contain private information, and if you are at all worried about that, you should not use this tool, or you should explicitly exclude those logs from the archive. xen-bugtool is wholly interactive, so simply run it, and answer the questions.