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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 7C471BBC4 for ; Thu, 5 Mar 2009 12:17:00 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgLAA9Dr0lQRFuwWmdsb2JhbACCfpF5ARYLDhSzLY9MgkkTgSwG X-IronPort-AV: E=Sophos;i="4.38,306,1233529200"; d="scan'208";a="22088546" Received: from furbychan.cocan.org ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2009 12:17:00 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1LfBZT-00082X-3p; Thu, 05 Mar 2009 11:16:59 +0000 Date: Thu, 5 Mar 2009 11:16:59 +0000 To: malc Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Message-ID: <20090305111659.GA30171@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> <20090305095621.GA26992@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 ocaml:01 ocaml:01 arbitrarily:01 bug:01 sizeof:01 sizeof:01 buf:01 malloc:01 buf:01 low-level:01 suboptimal:01 untrusted:01 trade-off:01 On Thu, Mar 05, 2009 at 01:49:01PM +0300, malc wrote: > You lost me here. Look at the patch I linked to [1]. > > - (Possibly) handling 32 and 64 bit quantities. > > Not possibly, definitely (in case of better being applied to current > implementation of OCaml) I'm not sure I mentioned OCaml, just a high level language. Anyway you can't make an argument about low level languages being better and then arbitrarily restrict my choice of high level language based on your definition of "current implementation". What does that mean? Only things published by INRIA? Maybe we shouldn't be allowed to use anything but the standard library too, to make this more "fair" towards low level languages? > > 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. Lack of a bounds check has _everything_ to do with C being at fault. The fact that this allows you to try out root exploits against the host from a guest is also everything to do with C. http://marc.info/?l=debian-security&m=120343592917055&w=2 > > 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. The problem is entirely with C. These fencepost errors to do with sizeof and strlen are frequent causes of errors in C. How many C programmers can honestly claim they haven't written this sort of thing at least once in their lives: buf = malloc (strlen (str)); strcpy (buf, str); Referring back to the original patch, in a high level language it wouldn't be necessary to pass a string + length into a function, because in a high level language we'd assume the function can just allocate a string of the required size. For this password case we would pass in the desired maximum length, so just the number '8'. _Far_ more obvious and less error prone. It's 2009, we shouldn't expect programmers to have to think about such stupid low-level stuff, and we shouldn't expect reviewers to check for it. Do you know how expensive it is to fix these security isses? Each one requires hundreds of man-hours building and validating packages, and then sending them out to sysadmins at all our customers who individually verify and install them. This is a vast undertaking which swamps the minute % increase in performance that C may (or even may not) give you. > > 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) I'm not sure what your point is. Bounds checking introduces some tiny overhead too. But if you don't do it, your untrusted guests can own your hosting service. Fair trade-off? Rich. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-02/txtzqRjC0boEM.txt -- Richard Jones Red Hat