Re: [Caml-list] stl?

[malc <av1474@comtv.ru>]

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