[coyotos-dev] DLL's

[Jonathan S. Shapiro]

On Wed, 2007-05-23 at 11:51 -0400, Christopher Nelson wrote:

> This opens up a lot more questions in my mind regarding the how of
> many things (like DLLs, and executable object mapping)...

It is, of course, possible to emulate these if the goal is to emulate
Linux. I assume your question concerns the "native" behavior.

The mechanics of DLL mapping actually aren't difficult.

DLLs are a can of worms at the conceptual level. One problem is that
applications rely on behavior in addition to interface. When a DLL is
updated, the interface may remain the same while the behavior changes in
a significant way. Many applications either (a) don't care, or (b)
prefer the risk of upgrade to the risk of existing, unrepaired errors,
or (c) prefer the risk of upgrade to the preservation of existing
security flaws. Other applications are what we might call "qualified",
in the sense that they have been tested against specific implementations
and need to continue to use those implementations. This can be handled
by static linking, but you may have noticed that static linking is going
the way of the dinosaur. The latest numbers are that 20% to 75% of the
code executed by a typical application comes from a library somewhere.

There is a security concern as well: the dynamic linker must be trusted
to honor confinement, in the sense that we must trust it to provide only
copy-on-write or {read,execute,!write} mappings to the application.
Otherwise our ability to test confinement would fail. Admitting the
dynamic linker into the mix is not unreasonable, since if the dynamic
linker screws up we haven't a clue what the application does in any
case, but it's not an issue to be ignored.

Finally, there is the issue that processes survive shutdown, and this
violates many of our assumptions about how quickly a new DLL will be
adopted by those applications that wish to do so.

So in the end, this all folds in to a general "object upgrade" problem
that is one of the really nasty sleeping dragons in the entire
object-based system story.


shap