Re: [lmi] Possible bug with configurable_settings and --data_path option

[Vadim Zeitlin]

On Wed, 17 Dec 2014 01:54:57 +0000 Greg Chicares <address@hidden> wrote:

GC> I'm afraid it's an instance of the "which came first, the chicken or the 
egg"
GC> problem. We want MswDllPreloader to do its work before any "foreign" dll can
GC> be loaded.

 Sorry if I'm missing something obvious but I still, in spite of your
explanations, don't understand why is it so. If a bad DLL is loaded early,
we can just reset the FPU control word to the sane state, can't we? AFAICS
the purpose of preloading the potentially bad DLLs is to prevent them from
changing the FPU state later unexpectedly, but this goal would still be
achieved even if we preloaded them later, we'd just need to make sure the
FPU state was set to known good state after doing it.

GC> We don't have a reproducible test case.

 I believe I could make one, i.e. write a malicious explorer hook DLL that
would change the FPU control word. I haven't done this kind of things
since quite some time (it's all XML and JavaScript nowadays, messing with
DLLs is so 1990s...), so it could take me a bit longer than I'd expect, but
if this problem is still relevant, it would be useful to have a test case
showing that the solution to it still works.

GC> But maybe you're less easily daunted, and I don't want to discourage you
GC> from trying to fix this.<...> What do you think?

 If we really can't postpone preloading the DLLs, then I am going to add
this to the end of my (relatively big) TODO list. But perhaps we can?

 What am I missing?
VZ