Re: [Caml-list] stl?

[malc <av1474@comtv.ru>]

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