gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: arch roadmap 1 (and "what's tom up to")
Date: Wed, 7 Jul 2004 08:56:50 -0700 (PDT)


    > From: Anselm Lingnau <address@hidden>

    > Jeremy Shaw wrote:

    >> I think the basic model is, the VM will have someway to mark
    >> commands as safe or unsafe. There will also be a way to set
    >> which unsafe commands a program can run on a per program, per
    >> command basis. This would allow you to implement a large number
    >> of possible security policies...

    > Sandboxing at the VM level isn't easy to get right, as, e.g.,
    > the Java folks have found out to their chagrin.

It might be helpful (to me at least) if you can report on what
problems they've had and why you think those problems stem from
sandboxing at the VM level rather than in some other way.


    > Incidentally, the frequently-maligned language Tcl does
    > sandboxing at what appears to amount to the Pika level in the
    > proposed arch-itecture, which seems to work rather well. Too bad
    > Tcl isn't politically acceptable for other reasons :^)

Tcl isn't _technically_ acceptable for fairly obvious reasons.  It is
(last I looked) lovely code.  It's so close it's a shame some details
were botched but, considering when it was first written, it's hardly a
surprise: the idea of using GC and heap-allocated environments and
continuations in a simple (rather than heavily optimized) interpreter
was fairly absurd at the time; trying to plan a VM that would allow
those things to be cleanly added later would have seemed a gratuitous
effort for the immediate goal which was roughly a shell-like language
but cleaner and easily embeddable.

And that's the root of the technical reason to not use Tcl: that it
is a low-ambition language design (aiming to be a cleaned up
shell-like language) that did not take pains to prepare for future
expansion into a more expressive language.   That was a big part of
the "Tcl wars" was a couple of us tryng to convicince John O. to 
tweak a few details of the semantics of Tcl to allow it to grow better
into something more powerful, but, probably since that lobbying was
taking place shortly after Sun had announced that Tcl would be the
"universal scripting language" it was not well received.

As for sandboxing at the "Pika level": I assume that you mean by
namespace manipulation; by being able to run sub-programs in an
environment in which only safe procedures can be referenced.

Sure, that works, and it works just fine for surface languages placed
on top of Furth.

The VM-level stuff we're talking about is just the idea of building in
additional protection at the VM-level in a form that resembled
privilege levels on a real CPU --- just a flag that certain primitives
can check to decide between running normally and signalling an error.




    > One of the lessons to learn from the sandbox feature in Tcl is that 
merely 
    > disallowing commands as »unsafe« doesn't quite cut it -- it is useful 
(and 
    > often necessary) to be able to execute nominally »unsafe« commands under 
    > carefully controlled circumstances (think of it as »user mode« vs. 
»kernel 
    > mode«). Tcl distinguishes between »safe interpreters« and »trusted 
    > interpreters«. In safe interpreters, potentially-dangerous commands are 
    > »hidden« and cannot be used in programs running in the safe interpreter; 
    > commands in a safe interpreter can »trap« into a trusted interpreter to 
do 
    > unsafe things (where the trusted interpreter will presumably check any 
    > arguments very carefully), and hidden commands in a safe interpreter can 
be 
    > invoked from a trusted interpreter.

That's not all that different, really.   The "trusted/untrusted" flag
on a Tcl interpreter object is analogous to the privilege-level flag
(or value) in Furth.


    > Personally I would much rather see arch »librified« rather than endowed 
with a 
    > VM and programming language all of its own (a Tcl/Tk binding would be 
nice). 
    > However, since Tom says what will happen, I just hope that the VM changes 
    > will also indeed accelerate the librification.

Doing furth implies librifying libarch.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]