553723 - use BindImageEx to bind function addresses in DLLs to the main executable

Status: NEW

(Firefox :: General, defect)

Description

[Dietrich Ayala (:dietrich)]

From Ehsan:

* Binding the firefox.exe after installation.
When Windows loads an executable image (which can be an .exe or .dll
file, but let's focus on .exe for now), it looks for each of the
functions that file imports from DLLs, loads the DLL files, computes
the address of every function imported, and puts that address inside a
part of the mapped exe image called the import address table (IAT).
This is done after each time that the exe is being loaded.  Windows
provides the BindImageEx API [1] which can be used to do this once and
for all.

VC (I think) ships a bind.exe tool which uses this API to bind exe
files.  I'm not sure if that's useful though, since we can call
BindImageEx from our installer as well, I think.  Note that this
doesn't help builds shipped with zip packages (because binding is
machine specific), and I think it will break things if DLLs are
updated (for things like OS upgrades), but we can make things work by
only binding our own DLLs (and making update.exe intelligent enough to
be able to handle all this.)

The only caveat here is that BindImageEx doesn't work on digitally
signed files (because the digital signature won't be valid if the file
is modified.)  I think we only sign firefox.exe, so at the very least
this can be done for all the DLLs that we ship.  And we might even
consider putting the entire code in a DLL and make firefox.exe a very
small image which just maps that DLL and hands off execution to it, so
that we can bind the DLL and keep the signature valid.

[1] http://msdn.microsoft.com/en-us/library/ms679279%28VS.85%29.aspx

Comment 1

[(not currently active) Ted Mielczarek]

(In reply to comment #0)
> The only caveat here is that BindImageEx doesn't work on digitally
> signed files (because the digital signature won't be valid if the file
> is modified.)  I think we only sign firefox.exe, so at the very least
> this can be done for all the DLLs that we ship.  And we might even
> consider putting the entire code in a DLL and make firefox.exe a very
> small image which just maps that DLL and hands off execution to it, so
> that we can bind the DLL and keep the signature valid.

No, we sign all the binaries in our release. Also, we're basically already doing the "one big DLL" thing with libxul, but we would rather switch to a static build instead (bug 525013).

Comment 2

[(no longer active)]

Hmm, I'm not sure if we should refrain from signing binaries in order to make binding possible.

But this will be a moot issue if we do static builds, which I understand that is a work in progress.

Comment 3

[(no longer active)]

Actually, I'm wrong in comment 2!  We can still consider binding for OS DLLs and any other DLLs which we can't squeeze into libxul (of firefox.exe).