[Cryptography] Transactional software updates

[Tom Mitchell]

On Tue, Oct 24, 2017 at 6:37 AM, Phillip Hallam-Baker <phill at hallambaker.com
> wrote:

> (Also posted to SUIT which is a proposed IETF WG on the topic, I
> thought it might be of interest here).
>
>
> I don't know about you, but I am fed up of the time it takes for
> software updates on my desktop. First the update has to be downloaded
> and then it has to be installed. Why can't this be instantaneous?
>
> What I would like is to

.......

> So installing a software update takes a millisecond,
> no more.
>
> Rolling back a software update is just a matter of telling the O/S to
> stop applying the overlay.
>

A lot depends on 'Software' in this context.
Too often the OS and software are joined at the hip.

For an operating system and all the applications in it this is a problem
that is bigger than a breadbox.

What your are asking for is broad atomic update of a versioning filesystem.
Stage 10,000 files and commit with an audit trail that can be reversed on an
OS that itself can depend on the files.

In linux one boot process begins with a boot loader that copies a bootstrap
operating system filesystem image into memory and starts the OS.   The OS
then
runs out of RamDisk to check the physical disks then mounts them and
'pivots'
to the OS on disk or even NFS This pivot and the continuation takes more
than a millisecond.

Specific applications are simpler:
Some Linux applications run out of a change root where files are copied or
perhaps
hard linked then chroot is invoked for the application (old or new but not
both right) which
then finds all the tools it needs and no more (hopefully).

A fresh chroot could be built and the original chroot process shutdown and
the new
one started almost quickly but the shutdown and restart would not be all
that quick
depending on the data.

A real problem is long running processes, shared libraries and open files.
Shared libraries in a system
are intended to apply to the entire system with minimum versioning.   A
running process has
many files open.   An editor on a handy machine 'vim' has 22 open files and
three devices (pty for stdin/out/err).
The 17 library fines (shared objects) that must be updated together (as
needed) with a new
version of the editor.
I recall a talk by White on Smalltalk where the Smalltalk system
interpreter could pick up
an edit to the editor source as quick as it hit the disk while still in the
editor.   If he made
an error the editor might be too broken to recover..

If you get the filesystem correct you have a versioning filesystem so tools
need to accept a version
flag or live with the current.

The system that lives on a versioning filesystem would need to be modified
to cope for interrupt free
operation.

Versioning in languages like 'go' need not depend on system shared
objects.
Eliminating shared libraries does simplify some entangling dependencies
at the expense of disk space and RAM.

Make and makedepend might need to be enhanced and baked into the OS.

GenToo does some of this now but milliseconds and going back -- not this
week.

Trix  (SGI's Trusted Irix) had mandatory access AMC features and MLD (multi
level directories and binaries)
where manipulation of labels for users, dirs, files an application could
only see files at the
same level or lower.  SELinux, WindowsNT and Win10 have some of these
strong mandatory access
tools.  And policy changes if made sufficiently atomic could be used to
flip a switch.
See the attribute structures in XFS (SGI's now open source filesystem)
where labels (meta data) are
stored.

Worth doing...
There must be a trusted nut to audit, fix and repair.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171025/79387eca/attachment.html>