lmi
[Top][All Lists]
Advanced

[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.




reply via email to

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