"PVE backup: rename incremental to use-dirty-bitmap" merged two
variables (use_dirty_bitmap and incremental) into one, but they served
two different purposes. Rename the original use_dirty_bitmap to
"expect_only_dirty" so the new one doesn't conflict, and rework "PVE:
use proxmox_backup_check_incremental" around that semantic.
In practice, this had the effect that only one disk at a time would
have a bitmap added, as after the first "use_dirty_bitmap" would be set
to one and the rest would behave as if the QMP parameter of the same
name was unset.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
* rename "incremental" param to "use-dirty-bitmap", avoids confusion
as the backup can be incrementally also with that param set to
false.
* use new proxmox_backup_check_incremental
* fix setting dirty counter and adapt to new connect API semantic
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Add trailing newline to two error messages, and drop an extra
unconditional `qdict_put_str(options, "driver", format);`
Besides that it's just formatting.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Move qemu_savevm_state_{header,setup} into the main loop and
the rest of the iteration into a coroutine. The former need
to lock the iothread (and we can't unlock it in the
coroutine), and the latter can't deal with being in a
separate thread, so a coroutine it must be.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Release the lock on qemu_coroutine_yield, so coroutines don't
deadlock.
Originally-by: Stefan Reiter <s.reiter@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the first two patches were mistakenly left out during the 4.2 qemu
rebase.
also adds another patch for issue CVE-2019-14378 (heap-based BOF)
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
The long overdue nice rebase+cleanup was done by Dietmar
Originally-by: Dietmar Maurer <dietmar@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
original commits and email can be found here[0]
A out-of-bounds heap buffer access issue was found in the SLiRP
networking implementation of the QEMU emulator. It occurs in tcp_emu()
routine while emulating IRC and other protocols due to unsafe usage of
snprintf(3) function.
A user/process could use this flaw to crash the Qemu process on the host
resulting in DoS or potentially execute arbitrary code with privileges
of the QEMU process on the host.
[0]: https://seclists.org/oss-sec/2020/q1/64
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
oss-security email can be found here[0]
upstream commit here[1]
this effects our vncproxy. dominik and me tested if the issue is present
on our branch and it appears that it is.
in essence when we disconnect from a vnc connection, the memory isn't
free'd afterwards which causes the qemu process to use more and more
memory with each disconnect, which could lead to a dos scenario.
we tested the patch and it seems to mitigate the problem.
[0]: https://seclists.org/oss-sec/2020/q1/105
[1]: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6bf21f3d83e95bcc4ba35a7a07cc6655e8b010b0
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
* Fix VMA tool build
* Change PVE code to new blockjob API
* Acquire missing lock for block_job_add_bdrv
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
