From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id E5A50BBC4 for ; Thu, 5 Mar 2009 10:56:27 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUIAAgwr0lQRFuwX2dsb2JhbACUdxcLCgQUww+ECAY X-IronPort-AV: E=Sophos;i="4.38,305,1233529200"; d="scan'208";a="23893513" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP; 05 Mar 2009 10:56:27 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1LfAJR-0007J0-L6; Thu, 05 Mar 2009 09:56:21 +0000 Date: Thu, 5 Mar 2009 09:56:21 +0000 To: malc Cc: yoann padioleau , Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Message-ID: <20090305095621.GA26992@annexia.org> References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903050131.03494.jon@ffconsultancy.com> <49AF35B8.9030104@naughtydog.com> <200903050326.57931.jon@ffconsultancy.com> <5001040.203359.1236234148184.JavaMail.www@wwinf2209> <20090305090621.GB24055@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; stl:01 malc:01 0100,:01 struct:01 bitfields:01 marshalling:01 manpage:01 literate:01 perl's:01 regexps:01 syntax:01 hacked:01 ocaml:01 overwrite:01 coefficients:01 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