peer-to-peer computation and security (was Re: [FoRK] kragen
Tony Finch <
dot at dotat.at
> on >
Fri Oct 13 12:27:45 PDT 2006
On Fri, 13 Oct 2006, Luis Villa wrote:
> On 10/13/06, Kragen Javier Sitaker <kragen at pobox.com> wrote:
> > That's largely what I'm talking about, although Mono is definitely
> > trying to take the language-runtime approach, as does E. As I said in
> > a recent message, I suspect that implementing this kind of protection
> > with multiple shared-nothing CPUs will likely be preferable to
> > implementing it with memory protection.
It's probably more correct to say that shared-nothing CPUs are not at so
much of a disadvantage when your programming model is based on message
passing. However there are nice optimizations you can make to message
passing languages on a conventional SMP, in particular zero-copy message
passing - though that has knotty implications for the garbage collector.
I should also mention Erlang, since it is the most serious contender (in
the suit and tie sense) in this field. Although its message passing model
is almost capability-based like E, it isn't designed with this in mind.
One consequence of this is that Erlang PIDs (equivalent to capabilities)
are forgeable using an obscure library function. So Erlang would need some
work to become as internally paranoid as E.
> So, capability-based, rather than access-based, security makes sense
> to me. Shouldn't this be at the OS level, though? Doing it at the app
> level seems to presume that the app is trusted to indicate its own
Yes, it should be at the OS level. We've become a bit distracted by
capabilities as a programming model rather than as a system design tool.
f.a.n.finch <dot at dotat.at> http://dotat.at/
FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN
OR SHOWERS. MODERATE OR GOOD.
More information about the FoRK