Xen devel - Sep 2008 - [PATCH] ioemu: various fixes to 18383:dade7f0bdc8d

I encountered ioemu SEGV while plaing with guest firmware.
Usually guest firmware doesn''t issue such IOs,
so it doesn''t matter. But malicious guest can do.
The following patch fixes it.

BTW, is there any plan to port the c/s of 18383:dade7f0bdc8d
to ioemu-remote?

thanks,

ioemu: various fixes to 18394:dade7f0bdc8d

various fixes to 18394:dade7f0bdc8d
- fix xc_memory_op(): handles XENMEM_remove_from_phsymap case.
- fix ioemu segv with old firmware
  Without notifying ioemu of address, ioemu will segv.
- fix qemu-dm segv with malicous firmware
  If notifying ioemu more than once, ioemu will segv.
Usually such cases don''t happen, but malicious guest can
do it intentionally.

Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>

diff -r 9b5e1e05e886 tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c	Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/cirrus_vga.c	Tue Sep 09 20:58:04 2008 +0900
@@ -2553,7 +2553,11 @@
         end = begin + VGA_RAM_SIZE;
 
     fprintf(logfile,"mapping vram to %lx - %lx\n", begin, end);
-
+    if (!s->vram_mfns) {
+        fprintf(logfile, "Found old firmware skiping mapping
vram\n");
+        return;
+    }
+    
     xatp.domid = domid;
     xatp.space = XENMAPSPACE_mfn;
 
diff -r 9b5e1e05e886 tools/ioemu/hw/vga.c
--- a/tools/ioemu/hw/vga.c	Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/vga.c	Tue Sep 09 20:58:04 2008 +0900
@@ -2080,7 +2080,13 @@
 
     if (copy)
         memcpy(vram, xen_vga_state->vram_ptr, VGA_RAM_SIZE);
-    qemu_free(xen_vga_state->vram_ptr);
+    if (xen_vga_state->vram_mfns) {
+        /* In case this function is called more than once */
+        free(xen_vga_state->vram_mfns);
+        munmap(xen_vga_state->vram_ptr, VGA_RAM_SIZE);
+    } else {
+        qemu_free(xen_vga_state->vram_ptr);
+    }
     xen_vga_state->vram_ptr = vram;
     xen_vga_state->vram_mfns = pfn_list;
 #ifdef CONFIG_STUBDOM
diff -r 9b5e1e05e886 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c	Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/libxc/xc_private.c	Tue Sep 09 20:58:04 2008 +0900
@@ -307,6 +307,13 @@
             goto out1;
         }
         break;
+    case XENMEM_remove_from_physmap:
+        if ( lock_pages(arg, sizeof(struct xen_remove_from_physmap)) )
+        {
+            PERROR("Could not lock");
+            goto out1;
+        }
+        break;
     case XENMEM_current_reservation:
     case XENMEM_maximum_reservation:
     case XENMEM_maximum_gpfn:
@@ -339,6 +346,9 @@
         break;
     case XENMEM_add_to_physmap:
         unlock_pages(arg, sizeof(struct xen_add_to_physmap));
+        break;
+    case XENMEM_remove_from_physmap:
+        unlock_pages(arg, sizeof(struct xen_remove_from_physmap));
         break;
     case XENMEM_current_reservation:
     case XENMEM_maximum_reservation:


-- 
yamahata

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Isaku Yamahata writes ("[PATCH] ioemu: various fixes to
18383:dade7f0bdc8d"):
> BTW, is there any plan to port the c/s of 18383:dade7f0bdc8d
> to ioemu-remote?
There aren''t generally any plans to cross-port patches made to
tools/ioemu in xen-unstable to the qemu-xen tree.  Furthermore,
tools/ioemu is going to go away fairly soon we hope so it is best to
avoid submitting patches against tools/ioemu unless essential.

If you submit a patch which ought to be in both trees you should say
so explicitly so that we can include it in both - which might mean
doing some fixup work.

Should I take your message as a request to cross-port 18383 and also
your fix, below, to qemu-xen (aka ioemu-remote) ?  These patches do
not apply to the qemu-xen-unstable tip.  If you''d like to resubmit
patches which do apply we should be able to commit them.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 09, 2008 at 02:35:05PM +0100, Ian Jackson
wrote:
> Isaku Yamahata writes ("[PATCH] ioemu: various fixes to
18383:dade7f0bdc8d"):
> > BTW, is there any plan to port the c/s of 18383:dade7f0bdc8d
> > to ioemu-remote?
> 
> There aren''t generally any plans to cross-port patches made to
> tools/ioemu in xen-unstable to the qemu-xen tree.  Furthermore,
> tools/ioemu is going to go away fairly soon we hope so it is best to
> avoid submitting patches against tools/ioemu unless essential.
> 
> If you submit a patch which ought to be in both trees you should say
> so explicitly so that we can include it in both - which might mean
> doing some fixup work.
Understood.

> Should I take your message as a request to cross-port 18383 and also
> your fix, below, to qemu-xen (aka ioemu-remote) ?  These patches do
> not apply to the qemu-xen-unstable tip.  If you''d like to resubmit
> patches which do apply we should be able to commit them.
My intention is
  When porting 18383 to qemu-xen, please make sure to port the fix too.
  However I''m not urgent for porting it.

My motivation was to keep xen/ia64 port working.
18383 broke xen/ia64 hvm domain, so I had to create the patch.
On the other hand, xen/ia64 is fine with the qemu-xen (At least when
I tested it last time.), thus I''m not urgent.

thanks,
-- 
yamahata

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel