[cap-talk] Security by safe language processing

[David-Sarah Hopwood]

Jed Donnelley wrote:
> David-Sarah Hopwood
> <mailto:cap-talk%40mail.eros-os.org?Subject=Re:%20%5Bcap-talk%5D%20Security%20by%20safe%20language%20processing&In-Reply-To=%3C4AA3231C.3000806%40jacaranda.org%3E>david-sarah
> at jacaranda.org
> Sat Sep 5 22:49:00 EDT 2009
> 
>> > Not only that, but the LBS system compilers and/or byte code verifiers
>> > must be valid against all possible inputs over a long range of time -
>> > perhaps all time.
>>
>> That is not necessarily the case. A system could be designed so that the
>> input to any code generation step is always kept, and the output is only
>> treated as a cache. Then, whenever the code generator is upgraded, the
>> cached output is invalidated and will be automatically regenerated as
>> needed. There have been language-based systems (for example Self) that
>> were able to do dependency checking and automatic recompilation at least
>> as complicated as this, although with different motivations.
> 
> Sorry I didn't see the above before firing off my last message.
> 
> I think I understand the above approach.  Do you agree that such an
> approach is very different from current systems in that with it
> one can't move binaries from system to system?

That depends what you call a "binary". In such a system, files containing
intermediate code (i.e. input to the trusted compiler(s)) serve exactly
the same role as binaries -- except that they are not dependent on
low-level machine architecture, which is a significant advantage.

> It seems to me that a cache invalidating event could have serious
> consequences for system performance - at least for a time.

In practice it would probably work as follows:

1. Install the new compiler.
2. In the background, recompile whatever subset of code is considered
   important for performance, probably including all code that is
   actually in memory at that point.
3. Invalidate all code (at turn boundaries where applicable).
4. Restart code compiled in step 2 immediately, and allow other code to
   be recompiled lazily as needed, perhaps being interpreted in the
   meantime.

Another practical issue is what happens when you have a bug in the new
compiler. To reduce the risk of changing all code at once when upgrading
to a compiler version with many changes, it is possible to allow a system
administrator more control over which compiler version is applied to
which code, but still enforce that security updates are never delayed
for more than a given maximum time.

In an orthogonally persistent system, forcing a system-wide checkpoint
before a compiler upgrade would also help.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com