Re: [lmi] MinGW-w64 anomaly?

[Vadim Zeitlin]

On Mon, 26 Dec 2016 10:10:05 +0000 Greg Chicares <address@hidden> wrote:

GC> lmi isn't the only application that checks the FP CW in idle time:
...
GC> Here's a case that specifically mentions DLL injection:
...
GC> And another:

 Yes, sorry for not making it clear, during my search (and even before it)
I did (had) definitely found (known of) the instances of the same problem
due to badly written DLLs, this is not in question.

 Just to close this topic, I think there are only 2 realistic scenarios in
which unknown/broken DLLs are loaded into the process:

1. On startup, using one of several ways to inject some DLL into all (or
   a particular, but usually all) processes in the system on startup.
2. Using some standard dialog, e.g. the file open/save one can load shell
   extensions (which are just special DLLs) and the print dialog might load
   some printer driver-specific DLLs too (but I'm not 100% sure about that).

 IOW it's still bad, but it's not arbitrarily bad in the sense that DLLs
won't be normally injected at any arbitrary time (of course, the latter is
still possible but this really has to be done intentionally and if there is
a Stuxnet-level malware running on the system targeting lmi, I think we've
already lost...).

GC> http://lists.nongnu.org/archive/html/lmi/2016-12/msg00063.html
GC> | [...] But I'm not sure we really need to use LMI_MSW
GC> | preprocessor checks: even if this code is not really needed under other
GC> | platforms (although, again, in principle nothing prevents a GTK+ theme or
GC> | macOS printer driver or whichever else shared library happens to be loaded
GC> | in the process from wreaking havoc with MXCSR), there is no harm in 
keeping
GC> | it there neither and fewer preprocessor checks the better IMO.
GC> 
GC> ...I now endorse your proposal not to restrict that check, and
GC> indeed to extend it to include MXCSR as well.

 Thanks, I'll do this.
VZ