a future caller alternative ?

Mark S. Miller erights at google.com
Sat Mar 9 18:57:52 PST 2013


On Sat, Mar 9, 2013 at 4:56 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> I really don't understand why the debugger thing is being trotted out
> again. It was addressed at the beginning of the thread: There are lots
> of real world applications that use debugger-style introspection (in
> particular, stack walking) for purposes that are not debugging.
>
> Now, to be fair, that may not justify exposing any of those features
> if the security threat posed by having introspection is so incredibly
> dire. But 'just use a debugger API' isn't really a solution for any of
> these applications. Debugger APIs are heavyweight and usually have
> tremendous performance consequences, preventing their use for solving
> Application Problems.


Another way to view the phrase "debugging API" is "properly stratified
privileged reflection API". Indeed, the famous Mirrors paper used JPDA as
an example of a properly stratified reflection system. The key thing about
debugging APIs is they get the privilege separation right -- because they
must. A well designed mirror system or mirror-like system could as well. I
have discussed this repeatedly with the co-authors of that paper -- Dave
Ungar and Gilad Bracha (cc'ed) -- and IIRC they enthusiastically agree. The
KeyKOS operating system had an operation for rights-amplifying a "start
key" or "resume key" to a "domain key". In our terms, a start key is like a
closure reference and a domain key is like a reference to the reified
lexical environment captured by that closure, i.e., a mirror on the state
of that closure. A resume key is like a continuation, so reflecting on
resume keys -- if you have the privileges needed to do so -- enables one to
effectively walk back the stack of outstanding IPC requests. The logic by
which KeyKOS (and its descendants EROS, CapROS, GuardOS, Coyotos) managed
the right-to-reflect could be a good starting point for doing likewise with
language-based mirrors.

This would be an excellent research topic for someone to take on. If
someone takes it on seriously, I may well be interesting in advising the
effort. However, the work of TC39 is not the right place to do this kind of
research (unless its crucial to an urgent goal, which this one isn't). Once
such research bears fruit, we can then consider whether to take this to
TC39 as a proposal for ESx, for some future x.



> In reality, the answer will have to be 'you
> can't do that in JavaScript', which probably isn't the end of the
> world since that's the current answer to anything that needs weak
> references.
>

I expect to propose weak references for ES7. I think I have an adequate
answer to the security issues that took this off the table for ES6. More
later.



>
> -kg
>
> On Sat, Mar 9, 2013 at 4:54 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > I do NOT want to write a debugger and yet I need caller, can you imagine
> ?
> >
> > Andrea
> >
> >
> > On Sat, Mar 9, 2013 at 10:44 AM, David Bruant <bruant.d at gmail.com>
> wrote:
> >>
> >> Le 08/03/2013 22:19, Andrea Giammarchi a écrit :
> >>
> >>> This opens doors to debuggers (introspection) and APIs magic quite a
> lot.
> >>
> >> If you want to write a debugger, use a debugger API [1] which is only
> >> executed in privileged environments, no?
> >>
> >> Debuggers are useful, but pierce encapsulation which is useful for
> program
> >> integrity. I don't think making a debugger API available to all
> programs is
> >> a good idea.
> >>
> >> David
> >>
> >> [1]
> >>
> https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> -kg
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130309/f715286c/attachment.html>


More information about the es-discuss mailing list