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.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id E2888BBC4 for ; Thu, 5 Mar 2009 11:48:56 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwDAO08r0lN6B+kmGdsb2JhbACBTpF9gTYBAQEBAQgJDAcRwwKECAY X-IronPort-AV: E=Sophos;i="4.38,306,1233529200"; d="scan'208";a="25103856" Received: from fe01x03-cgp.akado.ru (HELO akado.ru) ([77.232.31.164]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2009 11:48:56 +0100 Received: from [10.0.66.9] ([10.0.66.9] verified) by fe01-cgp.akado.ru (CommuniGate Pro SMTP 5.1.16) with ESMTP id 61589637; Thu, 05 Mar 2009 13:48:55 +0300 Date: Thu, 5 Mar 2009 13:49:01 +0300 (MSK) From: malc X-X-Sender: malc@linmac.oyster.ru To: Richard Jones Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? In-Reply-To: <20090305095621.GA26992@annexia.org> Message-ID: 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> <20090305095621.GA26992@annexia.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; malc:01 stl:01 malc:01 0100,:01 struct:01 bitfields:01 marshalling:01 manpage:01 literate:01 perl's:01 regexps:01 ocaml:01 syntax:01 hacked:01 ocaml:01 On Thu, 5 Mar 2009, Richard Jones wrote: > 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 Yes. > - Lists of structures are much simpler to represent and iterate over > in functional languages. You lost me here. > - 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. Yes. > - Unnecessary initialization of structures could be removed. Lost again. > - 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. Not possibly, definitely (in case of better being applied to current implementation of OCaml) > - (Possibly) bit manipulation. Again. > 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. I don't see how C per se is at fault here. > 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). Indeed. > 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. And again. > 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 ) The problem is not C's sizeof but the one who used it. > 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. Well this has nothing to do with C, which brings us to another interesting point, division by zero is UB as per 6.5.5#5, OCaml guarantees Division_by_zero being thrown in case of second operand by zero and the code it generates here on PPC to provide that is consequently suboptimal (cmp + branch per every division) > 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". I'm still not convinced that any of the above is due to using C and not just being lax at pre/post condition checking. > Rich. > > [1] http://lists.gnu.org/archive/html/qemu-devel/2009-02/txtzqRjC0boEM.txt > > -- mailto:av1474@comtv.ru