A proposal for increased security in wine - respecting previously expressed needs

[Reece Dunn]

2009/1/29  <alex at centroidcafe.com>:

> Hi, I've been lurking on this list for awhile, thinking about how I could
> contribute to Wine.
>
> I wanted to weigh in because I think this overall proposal is on the right
> track. Graceful handling of errors and crashes would provide a better user
> experience and potentially help increase the adoption of Wine by more
> casual users.
>
> I don't know much about application fault/exception handling, but couldn't
> Wine just install its own top-level fault handler on each Wine
> thread/process? That way, each API call in Wine can mimic the crash
> behavior of Windows to satisfy applications like InstallShield, but if the
> application doesn't handle the exception, the global Wine handler will pick
> it up and handle it gracefully.
>
> Please excuse me if I am totally off track here.

Microsoft did this kind of thing with XP (you can find documents
mentioning this on the net, I don't have any references to hand at the
moment).

With Vista they have gone the other way. In fact, in order to meet the
Windows Logo requirements on Vista you need to turn off structured
exception handling (SEH) in C++ exceptions and let the program crash
without disabling the Microsoft crash dialogs [1]. That is, if you
had:

    try { ((int *)0) = 10; } catch (...) { print("null pointer
dereference!\n"); }

using SEH trry/catch (/EHs) causes 'null pointer dereference' to be
printed on the console window and without (/EHa) causes the
application to crash, bringing up a "Report this problem to Microsoft"
dialog. Therefore, Microsoft are now advocating a crash early approach
to error handling.

Why is this important?

If you have an application that produces an error in method A that
sends a return code back to B that passes it back to C that returns a
different error code back to D where you report the issue, if that is
caused by a bug in method B (i.e. by passing a NULL to A because a
memory allocation failed) *how do you know*. All you know is that D
reported an error foo.

If you instead did not do a NULL pointer check on the argument, you
would have easily found that B is passing A a NULL argument - just
attach a debugger to the program.

I had some code that worked perfectly happily on XP, but crashed on
Vista. That was a bug in my code. I wouldn't have found it if Vista
had kept to trapping errors.

This is not to say that it should crash everywhere -- a lot of the
coverity issues are actually issues. In fact, these static analysis
and valgrind tools do a better job at spotting issues because of the
null pointer dereferences. These tools can track the issues back to
the call site and tell you exactly where the problem occurred. You
then check for null *there*.

- Reece

[1] http://www.google.co.uk/search?q=Windows+vista+guidelines+logo+crash&btnG=Search&hl=en&sa=2
-- "Certified for Windows Vista Requirements", section 3.2