[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Possible bug with configurable_settings and --data_path option
From: |
Greg Chicares |
Subject: |
Re: [lmi] Possible bug with configurable_settings and --data_path option |
Date: |
Wed, 17 Dec 2014 13:28:54 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 2014-12-17 02:30, Vadim Zeitlin wrote:
> 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.
That sounds extremely plausible. But it is a change in the originally-
designed behavior. Without a reproducible test case, I'm not willing
to be convinced that it's safe to change the behavior, no matter how
compelling the argument. The consequences of a mistake are too severe.
> 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.
However, that wouldn't necessarily behave the same way as the real-world
dlls that we're guarding against.
> 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.
Okay.
> But perhaps we can?
>
> What am I missing?
It's the nature of our conservative and rigidly regulated industry.