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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 18BE1BBC4 for ; Thu, 5 Mar 2009 13:39:39 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEDAO9Wr0lN6B+kmGdsb2JhbACBToEwkE2BNgEBAQEBCAkMBxGzX49WgkkTgSwG X-IronPort-AV: E=Sophos;i="4.38,307,1233529200"; d="scan'208";a="22093319" Received: from fe01x03-cgp.akado.ru (HELO akado.ru) ([77.232.31.164]) by mail2-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2009 13:39:38 +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 61632060; Thu, 05 Mar 2009 15:39:37 +0300 Date: Thu, 5 Mar 2009 15:39:43 +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: <20090305111659.GA30171@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> <20090305111659.GA30171@annexia.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; malc:01 stl:01 malc:01 ocaml:01 ocaml:01 arbitrarily:01 gcc:01 gcc:01 bug:01 sizeof:01 sizeof:01 buf:01 malloc:01 buf:01 low-level:01 On Thu, 5 Mar 2009, Richard Jones wrote: > 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? What i meant is that in current OCaml implementations overhead of using int32/64 is very high. > > > 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. Erm.. I don't agree, one can easily say that OCaml is only marginally better than C here just because `-unsafe' is not default on OCaml and `-fmudflap' is not in GCC (Let's be honest here QEMU is not written in C but dialect exposed by GCC) > 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); I thought we were discussing sizeof (mis)usage. > 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. I think you are confusing high levelness(whatever that might mean) with presence/lack-of GC of some sort. > 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? Not from the perspective of distribution maintainers. > 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. Until something like QEMU is (re)written in high-level language you have nothing to back that claim. > > > 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? My point is that inefficiencies like this do add up, other (weak) point is that in OCaml you can't even opt-out of (some) checks even if you have solid proof that, for instance, division by zero is impossible. I also think that device emulation would have been quite cumbersome in OCaml (Sorry for constantly refering to OCaml, but we are in dedicated mailing-list and i think thats the only language you would deem high-level and at the same time i happen to know to some degree) -- mailto:av1474@comtv.ru