[cap-talk] Memory access based OS security

[Jonathan S. Shapiro]

Bill's assertion is incorrect. The LBS need not rely any more strongly on
the compiler than the conventional system. I think he is assuming dynamic
compilation, which is not a necessary assumption. If compilation is static,
then the two cases are quite similar.

In most cases LBS safety relies merely on type and memory safety rather than
total correctness. Techniques such as TAL can provide this assurance, and
have other benefits in the form of broader compiler robustness. TAL is also
feasible in JITting systems, though harder.

Finally, I note in passing that LBS is not an "all or nothing" proposition.

shap

On Thu, Sep 3, 2009 at 11:48 PM, Jonathan M. Smith <jms at cis.upenn.edu>wrote:

> This was the appeal of EROS as a platform for SwitchWare. White paper made
> from proposal attached.-JMS
>
>
>
> Begin forwarded message:
>
> From: Bill Frantz <frantz at pwpconsult.com>
>> Date: September 3, 2009 8:43:34 PM EDT
>> To: "General discussions concerning capability systems." <
>> cap-talk at mail.eros-os.org>
>> Subject: [cap-talk] Memory access based OS security
>> Reply-To: "General discussions concerning capability systems." <
>> cap-talk at mail.eros-os.org>
>>
>> bklooste at gmail.com (Ben Kloosterman) on Monday, August 3, 2009 wrote:
>>
>> Hardware-level security through address management was introduced as a way
>>> to work around failures of
>>> the application languages (:shudder:, remembering early implementations
>>> of Windows). But if you force
>>> applications to compile to a particular language (or bytecode), you can
>>> enforce security at the
>>> software level and achieve security without the sacrifices to performance
>>> that come from partitioning
>>> the address space.
>>>
>>
>> The idea of depending on the compiler or byte code verifier in a "language
>> based system" (LBS) is quite attractive since it might result in a higher
>> performance system. However it does impact the assurance aspect of secure
>> systems.
>>
>> With systems like KeyKOS, EROS, CapROS, Coyotos, VM/370, etc. the security
>> assertion is that no sequence of machine language instructions is able to
>> subvert the security of the system. The only compiler that needs
>> verification is the one used to compile the system, and it only needs to
>> be
>> verified for the features used by the source code of the system. Since
>> only
>> a limited amount of programming needs to be verified, auditing the output
>> of the compiler is a feasible, if tedious, possibility.
>>
>> In contrast, LBS system compilers and/or byte code verifiers must be
>> verified against all possible inputs, which seems to me to be a harder
>> problem.
>>
>> Cheers - Bill
>>
>> -----------------------------------------------------------------------
>> Bill Frantz        | gets() remains as a monument | Periwinkle
>> (408)356-8506      | to C's continuing support of | 16345 Englewood Ave
>> www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090904/cdb8c2a5/attachment.html