qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] ui/vnc.c: Fix crash with VNC
Date: Sat, 10 Nov 2012 13:47:27 +0000

On Fri, Nov 9, 2012 at 7:13 AM, Gerhard Wiesinger <address@hidden> wrote:
> On 08.11.2012 22:07, Gerd Hoffmann wrote:
>>
>>    Hi,
>>
>>> I think this is fixing this at the wrong level. Either we
>>> should require that drivers (in this case vmware_vga.c)
>>> must not call dpy_gfx_update() with out of range values,
>>> or we should do the clipping in the console.c layer, but
>>> I don't think requiring every UI backend to clip is the
>>> right thing. Anthony?
>>
>> Agree.  IMHO vmware_vga.c is at fault here and should be fixed.  We can
>> add some asserts to console.[ch] to enforce this ...
>>
>
> Regarding fail safe programming I think it should be fixed/handled in both
> modules:
> vmware_vga.c should not trigger wrong values but also other modules should
> verify or even correct there input parameters.
> (think of situations where bits might not be accurate due to CPU bugs or
> even QEMU/KVM in aerospace where
> bits fall to other states due to high energy cosmic ray).
>
> Best solution is IHMO for vnc.c:
> 1.) Log the problem (that other modules can be fixed, too).
> 2.) Fix parameters (so that program doesn't crash)
>
> In mission critical software application like aerospace, airplanes, cars,
> etc. (e.g. where people might get unhealthy) handling such situations where
> input parameters aren't as expected is a must.

There are plenty of other considerations. For example, QEMU tests
don't have 100% code coverage, without even considering MC/DC. Adding
two overlapping checks could even result in <100% coverage.

Another issue is that the guest may cause QEMU to abort().

The code has not been formally reviewed, it's known to be in violation
to the few specifications we have (HACKING, CODING_STYLE, docs/*).

While QEMU is obviously a fine solution for many real world problems,
I don't recommend using QEMU for any safety critical tasks.

> See:
> https://en.wikipedia.org/wiki/Fail-safe
> https://en.wikipedia.org/wiki/Cosmic_ray#Effect_on_electronics
> https://en.wikipedia.org/wiki/Radiation_hardening
>
> Precondition:
> https://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Design_by_Contract
>
> Ciao,
> Gerhard
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]