On Thu, Mar 05, 2009 at 12:34:54PM +0300, malc wrote:
> On Thu, 5 Mar 2009, Richard Jones wrote:
> 
> > On Thu, Mar 05, 2009 at 07:22:28AM +0100, yoann padioleau wrote:
> > > Qemu is written in C, because I guess indeed C struct and union
> > > and bitfields makes it easy to match directly to the hardware (no marshalling,
> > > there is direct mapping).
> > 
> > I was hacking on qemu last week, and wishing it wasn't written in C.
> 
> I'm genuinely curious as to what part of QEMU being not written in C
> would have been a net win..

I'm not saying we should rewrite QEMU, but using a higher level
language would mean the code was shorter and easier to understand.

Just to take some examples from how my latest patch[1] would have been
shorter and easier to reason about:

- Could represent manpage & command line arguments in a self-documenting
  literate format, eg. Perl's perldoc + Pod::Usage

- Lists of structures are much simpler to represent and iterate over
  in functional languages.

- Parsing the command line is a lot simpler when you don't have to
  worry about manual string allocation and you have high level features
  like regexps, split, etc.

- Unnecessary initialization of structures could be removed.

- Serialization of watchdog structure could have been done automatically
  (eg. by something like sexplib)

And for balance some things that C is better at:

- (Possibly) handling 32 and 64 bit quantities.

- (Possibly) bit manipulation.

Although I'm not convinced that we couldn't do better using pa_do and
some sort of enhanced bitstring syntax extension.

And of course:

- Unlimited number of monkeys to write code (see below).

> > There's not much of a technical reason why it couldn't have been
> > written in a higher level language.  Bitfield manipulation would be
> > more painful unless there was a bitstring-like preprocessor added.
> >
> > The real reason to use C was to get wider development support.  Qemu
> > also happens to be security critical (all those hacked up C device
> > emulations offer exploit possibilities for the guests).  And it has
> > frequent vulnerabilities.  Go figure ...
> 
> I'm sorry, but i don't see how writing device emulation in OCaml would
> have made it automatically safer.

CVE-2008-0928:
| Qemu 0.9.1 and earlier does not perform range checks for block device
| read or write requests, which allows guest host users with root
| privileges to access arbitrary memory and escape the virtual machine.

CVE-2008-1945
| QEMU 0.9.0 does not properly handle changes to removable media, which allows
| guest OS users to read arbitrary files on the host OS by using the
| diskformat: parameter in the -usbdevice option to modify the disk-image
| header to identify a different format, a related issue to CVE-2008-2004.
(Arguable whether this one is really about C, but a safe extension
like bitstring would have prevented it).

CVE-2007-1320
| The cirrus_invalidate_region() routine used during video-to-video copy
| operations in the cirrus vga extension code omits bounds checking in
| multiple locations, allowing you to overwrite adjacent buffers by
| attempting to mark non-existent regions as dirty. Successful
| exploitation would result in a complete compromise of the qemu
| process. Additionally multiple bitblt operations omit bounds checking,
| where the srcpitch or dstpitch coefficients cause the operation to
| exceed the bounds of the vram buffer.

CVE-2008-5714
| Fix off-by-one bug limiting VNC passwords to 7 chars 
(Problem in C's sizeof:
http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg01224.html )

CVE-2007-1366
| QEMU 0.8.2 allows local users to crash a virtual machine via the
| divisor operand to the aam instruction, as demonstrated by aam 0x0,
| which triggers a divide-by-zero error.

CVE-2007-6227
| QEMU 0.9.0 allows local users of a Windows XP SP2 guest operating
| system to overwrite the TranslationBlock (code_gen_buffer) buffer,
| and probably have unspecified other impacts related to an overflow,
| via certain Windows executable programs, as demonstrated by
| qemu-dos.com.

CVE-2008-2004
| The drive_init function in QEMU 0.9.1 determines the format of
| a raw disk image based on the header, which allows local guest
| users to read arbitrary files on the host by modifying the header
| to identify a different format, which is used when the guest is
| restarted.

Those are just from the results of the first page of Google "qemu CVE".

Rich.

[1] http://lists.gnu.org/archive/html/qemu-devel/2009-02/txtzqRjC0boEM.txt

-- 
Richard Jones
Red Hat