Re: shared "system" libraries

[Marcus Brinkmann]

At Fri, 09 Dec 2005 12:38:44 -0500,
>   1. An application must be able to select the library versions
>      that it will accept. In particular, it must be able to say
>      "I have only been tested with version 5.4.9.8.2.1, and upgrades
>      are not okay for me."

I was not talking about this, because its an orthogonal problem to me,
and one that we have solutions for.  I am specifically thinking about
a combination of ELF shared libraries, which are at least well
understood and work OK in practice, together with per-process name
spaces that are composed of per-package-versions filesystems.

Here is how this is done in more detail.  There is one filesystem (or
directory hierarchy, if you want), per package _and_ version.

/packages/bash-3.0-16/bin/bash
...

The dependencies between packages are of course recorded in the
packages database.  We have lots of experience handling such
dependencies from Debian GNU/Linux, which has done fine-grained
dependencies, including versioned dependencies, on a large scale
(thousands of packages) over a long period of time (several years)
including several major upgrades (even going from Herbert Xu's libc5
to GNU's glibc, which was a major headache).  So, this is something we
understand pretty well.

The actual filesystem that the user sees is then the union of the
individual packages that the user wants (including their
dependencies), plus the mutable user's application and/or data
directories.  The concept of a unionfs is also emerging in BSD and
Linux, and one has also been developed for the Hurd, and the semantics
such a unionfs should have are emerging, I think.

With a package management system that keeps packages and versions
completely separate, and can dynamically and per-process configure
consistent sub-sets of packages (including resolving conflicts and
versioned dependencies), we also solve an important other problem:
Currently, in Debian GNU/Linux, only one version of each package can
be installed.  On upgrade, you actually may break existing running
programs, because they run code from the old version and access (for
example data) files from the new version.

With this setup, the remaining problem is the durability of the old
versions of the packages:
 
>   2. A shared library should be retained until its last client
>      lets it go.
>
> But I think that the storage payment issue is actually not a problem. In
> practice, when we install applications on a machine, they either come
> from system-wide storage or per-user storage. If the application is
> shared, it comes from system-wide storage. As long as this is true, we
> simply need a "registry" for tracking shared library dependencies. It is
> *not* necessary for every application to have its own copy of read-only
> code.

The problem I see is that tracking the shared library dependencies has
not to be done for the installed packages (only), but for the actual
running program (application) instances.

Until I am missing something, this means reference counting.

> There is a very natural place to do this: in the application
> installer/de-installer interface.

I don't see the installer or package manager track run-time
dependencies of all processes.  Actually, I'd say that if the package
manager and filesystem are merged (as I propose above), then yes, the
package manager would need to know about run-time dependencies, but in
practice I would still call it the filesystem that knows about it, and
the package manager receives this information from the filesystem
(which I'd consider to be logically separate, although interacting).

> So: this is a "negotiation of durability" problem and a versioning
> problem. Negotiating durability is actually hard.

Okay, so it's hard.  That's what I wanted to say ;)

> One point in particular: solving this requires that VCSK be moved into
> the TCB. When we make a virtual copy of a space, we need a reference
> counting mechanism to know when the underlying space can be reclaimed
> without breaking a running program. This reference count is a downward
> communication (though a minor one). Unfortunately, it violates
> confinement and so needs to be handled by trusted code.

What's a VCSK?

Sounds like this actually addresses the problem I wanted to talk
about.  However, to make sure we would need to look closer at the
actual mechanisms and how they are used.

Thanks,
Marcus