Re: [Qemu-devel] Taking live snapshots of running VMs
On Sat, Jul 9, 2011 at 05:24, Ahmed M. Azab ama...@ncsu.edu wrote: Hi All, Is there a way to take a live memory snapshot of a running VM without freezing or stopping this VM? something like what Xen does with live migration by using incremental page migration (or something named like that?)? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
[Qemu-devel] [Bug 807893] [NEW] qemu privilege escalation
Public bug reported: If qemu is started as root, with -runas, the extra groups is not dropped correctly /proc/`pidof qemu`/status .. Uid:100 100 100 100 Gid:100 100 100 100 FDSize: 32 Groups: 0 1 2 3 4 6 10 11 26 27 ... The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. The extra gid's allow read or write access to other files (such as /dev etc). Emulating the qemu code: # python ... import os os.setgid(100) os.setuid(100) os.execve(/bin/sh, [ /bin/sh ], os.environ) sh-4.1$ xxd /dev/sda | head -n2 000: eb48 9000 .H.. 010: sh-4.1$ ls -l /dev/sda brw-rw 1 root disk 8, 0 Jul 8 11:54 /dev/sda sh-4.1$ id uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) ** Affects: qemu Importance: Undecided Status: New ** Tags: escalation groups privilege security -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/807893 Title: qemu privilege escalation Status in QEMU: New Bug description: If qemu is started as root, with -runas, the extra groups is not dropped correctly /proc/`pidof qemu`/status .. Uid:100 100 100 100 Gid:100 100 100 100 FDSize: 32 Groups: 0 1 2 3 4 6 10 11 26 27 ... The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. The extra gid's allow read or write access to other files (such as /dev etc). Emulating the qemu code: # python ... import os os.setgid(100) os.setuid(100) os.execve(/bin/sh, [ /bin/sh ], os.environ) sh-4.1$ xxd /dev/sda | head -n2 000: eb48 9000 .H.. 010: sh-4.1$ ls -l /dev/sda brw-rw 1 root disk 8, 0 Jul 8 11:54 /dev/sda sh-4.1$ id uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/807893/+subscriptions
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
** Changed in: qemu Status: New = Confirmed ** Changed in: qemu Assignee: (unassigned) = Stefan Hajnoczi (stefanha) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/807893 Title: qemu privilege escalation Status in QEMU: Confirmed Bug description: If qemu is started as root, with -runas, the extra groups is not dropped correctly /proc/`pidof qemu`/status .. Uid:100 100 100 100 Gid:100 100 100 100 FDSize: 32 Groups: 0 1 2 3 4 6 10 11 26 27 ... The fix is to add initgroups() or setgroups(1, [gid]) where appropriate to os-posix.c. The extra gid's allow read or write access to other files (such as /dev etc). Emulating the qemu code: # python ... import os os.setgid(100) os.setuid(100) os.execve(/bin/sh, [ /bin/sh ], os.environ) sh-4.1$ xxd /dev/sda | head -n2 000: eb48 9000 .H.. 010: sh-4.1$ ls -l /dev/sda brw-rw 1 root disk 8, 0 Jul 8 11:54 /dev/sda sh-4.1$ id uid=100(qemu00) gid=100(users) groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/807893/+subscriptions
[Qemu-devel] [PATCH] os-posix: set groups properly for -runas
Andrew Griffiths reports that -runas does not set supplementary group
IDs. This means that gid 0 (root) is not dropped when switching to an
unprivileged user.
Add an initgroups(3) call to use the -runas user's /etc/groups
membership to update the supplementary group IDs.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
Note this needs compile testing on various POSIX host platforms. Tested on
Linux. Should work on BSD and Solaris. initgroups(3) is SVr4/BSD but not in
POSIX.
os-posix.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/os-posix.c b/os-posix.c
index 7dfb278..6f8d488 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -31,6 +31,7 @@
/*needed for MAP_POPULATE before including qemu-options.h */
#include sys/mman.h
#include pwd.h
+#include grp.h
#include libgen.h
/* Needed early for CONFIG_BSD etc. */
@@ -199,6 +200,11 @@ static void change_process_uid(void)
fprintf(stderr, Failed to setgid(%d)\n, user_pwd-pw_gid);
exit(1);
}
+if (initgroups(user_pwd-pw_name, user_pwd-pw_gid) 0) {
+fprintf(stderr, Failed to initgroups(\%s\, %d)\n,
+user_pwd-pw_name, user_pwd-pw_gid);
+exit(1);
+}
if (setuid(user_pwd-pw_uid) 0) {
fprintf(stderr, Failed to setuid(%d)\n, user_pwd-pw_uid);
exit(1);
--
1.7.5.4
Re: [Qemu-devel] Taking live snapshots of running VMs
On Fri, Jul 8, 2011 at 11:24 PM, Ahmed M. Azab ama...@ncsu.edu wrote: Is there a way to take a live memory snapshot of a running VM without freezing or stopping this VM? You could add a bit of code that forks QEMU. The kernel does memory copy-on-write across fork(2). Make sure not to use file-backed/shared memory for guest RAM (but that's okay since it is the default). The child process could write out the memory image and then terminate - or it could sit around waiting for you to inspect it with GDB or some other mechanism. If you kill the child process then you lose access to that memory snapshot. For production I'm not convinced that this feature is useful. There is already support for crash dumping and kernel debugging of guest OSes. The mechansim various by guest OS, but it works similar to on a physical machine. What system analytics or forensics exactly are useful when you only have access to guest *physical* memory? Seems like a development feature that you can hack on locally in a few lines of code but not something for production. Stefan
[Qemu-devel] failed migration makes monitor stuck
After some debugging I found a programming error in error handling in migration, but I'm not sure how to fix it. When migration starts, monitor gets suspended, calling monitor_suspend() routine which increments assotiated suspend_cnt counter. At the end of migration, in migrate_fd_cleanup(), monitor_resume() gets called, which decrements the counter. But monitor_resume() gets also called from another place, in migrate_fd_put_buffer(), in case we encountered a write error. So, suppose a tcp endpoint has disconnected, or the exec: program terminated due to error or whatnot -- in all these cases write will fail, and we'll call monitor_resume() twice as a result: once in this place in migrate_fd_put_buffer(), and once more at the end in migrate_fd_cleanup(). This results in suspend_cnt being decremented twice, with the resultant value being -1. So monitor_can_read() will return 0 from now on, since it compares suspend_cnt with 0. And hence, monitor will stop working. To me it looks like monitor_resume() call should be removed from migrate_fd_put_buffer(), but I'm not sure _why_ it were here in the first place. There's more: monitor_suspend() gets called from within protocol handlers (using migrate_fd_monitor_suspend() routine), -- are we sure that all current and future protocol handlers will call this function? Thanks! /mjt
Re: [Qemu-devel] [PATCH v8 10/12] VMDK: create different subformats
On Fri, Jul 8, 2011 at 11:29 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Jul 5, 2011 at 12:31 PM, Fam Zheng famc...@gmail.com wrote:
Add create option 'format', with enums:
The -drive format=... option exists in QEMU today to specify the image
format of a file. I think adding a format=... creation option may
lead to confusion.
How about subformat=... or type=...?
Each creates a subformat image file. The default is monolithiSparse.
s/monolithiSparse/monolithicSparse/
@@ -243,168 +243,6 @@ static int vmdk_is_cid_valid(BlockDriverState *bs)
return 1;
}
-static int vmdk_snapshot_create(const char *filename, const char
*backing_file)
Is this function really not needed anymore?
I think so. This function is not used to create snapshot, actually
it's called for backing file. It copies header and L1 table, allocate
L2 tables and leave them zero. This is equivalent to creating a new
extent. The only difference is to set descriptor options parentCID and
parantFileNameHint.
@@ -1189,28 +990,317 @@ static int vmdk_create(const char *filename,
QEMUOptionParameter *options)
}
}
- /* compose the descriptor */
- real_filename = filename;
- if ((temp_str = strrchr(real_filename, '\\')) != NULL)
- real_filename = temp_str + 1;
- if ((temp_str = strrchr(real_filename, '/')) != NULL)
- real_filename = temp_str + 1;
- if ((temp_str = strrchr(real_filename, ':')) != NULL)
- real_filename = temp_str + 1;
- snprintf(desc, sizeof(desc), desc_template, (unsigned int)time(NULL),
- total_size, real_filename,
- (flags BLOCK_FLAG_COMPAT6 ? 6 : 4),
- total_size / (int64_t)(63 * 16));
-
- /* write the descriptor */
- lseek(fd, le64_to_cpu(header.desc_offset) 9, SEEK_SET);
- ret = qemu_write_full(fd, desc, strlen(desc));
- if (ret != strlen(desc)) {
+ filesize -= filesize;
What is the point of setting filesize to zero?
+ ret = 0;
+ exit:
+ close(fd);
+ return ret;
+}
+
+static int vmdk_create_flat(const char *filename, int64_t filesize)
+{
+ int fd, ret;
+
+ fd = open(
+ filename,
+ O_WRONLY | O_CREAT | O_TRUNC | O_BINARY | O_LARGEFILE,
+ 0644);
+ if (fd 0) {
+ return -errno;
+ }
+ ret = ftruncate(fd, filesize);
+ if (ret) {
ret = -errno;
- goto exit;
+ close(fd);
+ return -errno;
errno is a global variable that may be modified by any errno-using
library function. Its value may be changed by close(2) (even if there
is no error closing the fd). Therefore please do return ret instead
of return -errno.
}
+ close(fd);
+ return 0;
+}
- ret = 0;
+static int filename_decompose(const char *filename, char *path, char
*prefix,
+ char *postfix, int buf_len)
Memory sizes (e.g. buffer size) should be size_t (which is unsigned)
instead of int.
+{
+ const char *p, *q;
+
+ if (filename == NULL || !strlen(filename)) {
+ fprintf(stderr, Vmdk: wrong filename (%s)\n, filename);
Printing filename doesn't make sense since filename is either NULL or
. Also note that fprintf(..., %s, NULL) is undefined and may
crash on some platforms (e.g. Solaris).
+ return -1;
+ }
+ p = strrchr(filename, '/');
+ if (p == NULL) {
+ p = strrchr(filename, '\\');
+ }
+ if (p == NULL) {
+ p = strrchr(filename, ':');
+ }
+ if (p != NULL) {
+ p++;
+ if (p - filename = buf_len) {
+ return -1;
+ }
+ strncpy(path, filename, p - filename);
+ path[p - filename] = 0;
+ } else {
+ p = filename;
+ path[0] = '\0';
+ }
+ q = strrchr(p, '.');
+ if (q == NULL) {
+ pstrcpy(prefix, buf_len, p);
+ postfix[0] = '\0';
+ } else {
No check for prefix buf_len here. Imagine filename has no '/', '\\',
or ':' but it does have a '.'. It is possible to overflow prefix.
+ strncpy(prefix, p, q - p);
+ prefix[q - p] = '\0';
+ pstrcpy(postfix, buf_len, q);
+ }
+ return 0;
+}
+
+static int relative_path(char *dest, int dest_size,
+ const char *base, const char *target)
+{
+ int i = 0;
+ int n = 0;
+ const char *p, *q;
+#ifdef _WIN32
+ const char *sep = \\;
+#else
+ const char *sep = /;
+#endif
+
+ if (!(dest base target)) {
+ return -1;
+ }
+ if (path_is_absolute(target)) {
+ dest[dest_size - 1] = '\0';
+ strncpy(dest, target, dest_size - 1);
+ return 0;
+ }
+ while (base[i] == target[i]) {
+ i++;
+ }
+ p = base[i];
+ q = target[i];
+ while (*p) {
+ if (*p == *sep) {
+ n++;
+ }
+ p++;
+ }
+ dest[0] = '\0';
+ for (; n; n--) {
+ pstrcat(dest, dest_size, ..);
+ pstrcat(dest, dest_size, sep);
+ }
[Qemu-devel] [PATCH v2] esp: cancel current request only if some request is in flight
This bug was introduced in 94d3f98a3f3caddd7875f9a11776daeb84962a7b:
scsi_cancel_io was checking if some request was pending before trying
to cancel it, while scsi_req_cancel always cancels the request.
This may lead to a crash of Qemu due to dereferencing a NULL pointer,
as exhibited by NetBSD 5.1 installer on MIPS Magnum emulation.
Signed-off-by: Hervé Poussineau hpous...@reactos.org
---
Changes since v1:
- better commit message
hw/esp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/esp.c b/hw/esp.c
index 8e95672..aa50800 100644
--- a/hw/esp.c
+++ b/hw/esp.c
@@ -219,7 +219,7 @@ static uint32_t get_cmd(ESPState *s, uint8_t *buf)
s-ti_rptr = 0;
s-ti_wptr = 0;
-if (s-current_dev) {
+if (s-current_req) {
/* Started a new command before the old one finished. Cancel it. */
scsi_req_cancel(s-current_req);
s-async_len = 0;
--
1.7.5.4
[Qemu-devel] [Bug 568614] Re: x86_64 host curses interface: spacing/garbling
for which version is the last patch? also 12.3? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/568614 Title: x86_64 host curses interface: spacing/garbling Status in QEMU: In Progress Bug description: Environment: Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3 Steps to reproduce: 1. Have a host system running 64-bit Linux. 2. Start a qemu VM with the -curses flag. Expected results: Text displayed looks as it would on a real text-mode display, and VM is therefore usable. Actual results: Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible. The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine. I don't know enough of the semantics of console_ch_t to know if this is the correct fix or if there should be, say, an extra cast somewhere instead. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/568614/+subscriptions
[Qemu-devel] [Bug 568614] Re: x86_64 host curses interface: spacing/garbling
Pretty sure it was the latest Arch package: 0.14.1. Did you have trouble applying it? I can run back and make a patch against git if you can't use this. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/568614 Title: x86_64 host curses interface: spacing/garbling Status in QEMU: In Progress Bug description: Environment: Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3 Steps to reproduce: 1. Have a host system running 64-bit Linux. 2. Start a qemu VM with the -curses flag. Expected results: Text displayed looks as it would on a real text-mode display, and VM is therefore usable. Actual results: Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible. The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine. I don't know enough of the semantics of console_ch_t to know if this is the correct fix or if there should be, say, an extra cast somewhere instead. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/568614/+subscriptions
[Qemu-devel] Votre maison est équipée d'un chauffage central ?
Votre maison est équipée d'un chauffage central ? Vous pouvez installer une pompe à chaleur air-eau en relève ou en remplacement de chaudière et réaliser jusqu'à 80% d'économies de combustible. Par ailleurs vous pouvez bénéficier d'un crédit d'impôt pour toutes vos dépenses d'installation d'une Pompe à Chaleur ou pour La pose de panneaux photovoltaïques Vous ne payez pas ou peu d'impôts? le crédit vous est remboursé ! Le Grenelle de l'Environnement a prévu des aides pour 2011: Profitez-en pendant qu'elles sont là... Ne laissez pas passer cette opportunité Demandez votre étude gratuite et sans engagement de votre part La pose de panneaux photovoltaïques vous permet de devenir producteur d’énergie et de revendre votre électricité à EDF* Vous possédez une propriété, un entrepôt, un bâtiment industriel, une grange ou vous voulez construire un abri, un au vent, un garage, un hangar équipés de panneaux solaires photovoltaïques … Un revenu complémentaire durable pendant 20 ans. NE LAISSEZ PAS VOTRE TOIT INACTIF Vous pouvez bénéficier d’un crédit d’impôts, et généré un revenue de 800€*, 1000€*, 5 000€*, 10 000€*, ou et plus chaque année facturés à EDF* pendant 20 ans garantie par EDF* (*sous réserve d'acceptation du dossier et du raccordement par EDF ) RRFONTAINE-EAU8899.JPGRRANNULATION.JPG
