Author Topic: new driver development.  (Read 3257 times)

Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #15 on: December 31, 2017, 06:52:58 AM »

I am definitely more worried about in-game users getting access to the filesystem outside the scope of the mudlib.  Mudlib development has lagged behind a bit but I hope to have the dev version of the lib up in the next couple of days.  Node makes things a bit trickier if you allow async calls.  An async write callback stack will not include the callstack entries that triggered the write in the first place so all such operations need to be handled in the driver so the context can be created and restored when the callback fires.

[Today I wrote 'ed' for telnet clients... or most of it... I am pretty proud of my little line editor so far ;-) https://github.com/kristianoye/kmud/blob/master/src/features/MUDEditor.js]

The security model is stack-based so each object on the stack is checked to ensure it has access to perform the operation so when I type "rm /log/errors/kriton"

The rm command calls efuns.rm(file) which calls driver's validWrite() which generates a list of objects to check based on the stack (/sys/cmds/creator/Rm, /v/sys/data/creators/k/kriton).  The driver then calls the validWrite() apply in the driver for each object.  If any one of the objects fails the check then the entire operation fails.

Code: [Select]
> ed /log/test.log
Starting editor.
*               This is a test.
*       .
[/log/test.log]*: w
You encountered an error.
Error: Permission denied: /log/test.log
    at EFUNProxy.writeFile ([driver]\EFUNProxy.js:1035:19)
    at EditorInstance.writeFile ([driver]\features\MUDEditor.js:519:20)
    at EditorInstance.executeCommand ([driver]\features\MUDEditor.js:280:37)
    at EFUNProxy.efunPrototype.(anonymous function) [as editorCmd] ([driver]\features\MUDEditor.js:585:42)
    at executeEditor (/base/Interactive.js:73:44)
    at CreatorWrapper.processInput (/base/Interactive.js:239:34)
    at CreatorWrapper.preprocessInput (/base/Creator.js:156:25)
    at CreatorWrapper.preprocessInput (/v/sys/data/creators/k/kriton:13:51)
    at MUDStorage.Interactive.$storage.prependListener (/base/Interactive.js:285:25)
    at MUDStorage.emit ([driver]\MUDEventEmitter.js:31:34)

Exceptions are also tricky since Node does not give you a means to intercept creation of errors at the source.  I have logic to scrub the external filesystem from most errors but someone can just do a try ... catch and display the error to get the native path.  Having the native path should not gain you much but it is more than I like.  I might just disallow exception handling in the compiler and force users to rely on the driver-based exception handler and reporting.

Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #16 on: January 15, 2018, 03:52:19 AM »
I ran into a snag with tripwire not working as expected.  I am trying to get it working the way I want but my C++ is a bit rusty.

> eval while(true);
Command exceeded max execution time.
> You encountered an error:Max execution time exceeded.
    at :1:38
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)

(it keeps throwing exceptions though and doesn't yet resume the original thread).

Offline silenus

  • BFF
  • ***
  • Posts: 193
    • View Profile
Re: new driver development.
« Reply #17 on: January 15, 2018, 05:06:06 AM »
Do you have a link for where I might get the source code for tripwire? I am kind of curious what it's capabilities are.

Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #18 on: January 15, 2018, 04:29:07 PM »

https://github.com/tjanczuk/tripwire/tree/master/src

I've managed to get rid of the non-stop exceptions but still haven't figured out why Isolate::IsExecutionTerminating() remains false.  I really need to figure out how to enable debugging in VS so I can step into the C++.

Offline silenus

  • BFF
  • ***
  • Posts: 193
    • View Profile
Re: new driver development.
« Reply #19 on: January 15, 2018, 06:41:47 PM »
I am not a C++ expert but looking at the tripwire code it seems to do something relatively simple in concept which is to kill threads on a sort of timeout. I guess I would have to understand node.js a bit better to understand how it truly works is v8 multithreaded?

Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #20 on: January 20, 2018, 06:15:19 PM »
V8 itself uses multiple threads but script isolates are not.  V8 may execute multiple isolates, though, but as the name suggests they don't interact.

I decided to instrument scripts in the pipeline for now (seems like an easier solution since tripwire requires a native binary on each platform).

Code: [Select]
        while (true) {
            write(`x = ${x++}`);
        }

Transpiles into:

Code: [Select]
        while (true) {
            __ala(); write(`x = ${x++}`);
        }

__ala (assert loop alarm) and __afa (assert function alarm) are protected identifiers.  Trying to redefine them in a module will also throw an error.


Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #21 on: January 27, 2018, 10:24:36 PM »
I am relying more and more on instrumentation.  I am now trying to use it to maintain the object stack but allowing async code makes things so messy.  I really don't want to insert an actual context reference in user code but... I need to go buy a whiteboard I think.  A method is called, the current object/method are put on a stack but if there is a context while executing that method things get messy fast.

Code: [Select]
    cmd(args, cmdline) {
        __bfc(this, 'cmd'); try { let player = thisPlayer,
            dirList = [],
            options = 0,
            flags = 0;

        for (let i = 0; i < args.length; i++) {
            __ala(); let opt = args[i];
            ...
        }
        ...
        this.removeDirectories(dirList, flags, options, cmdline); <-- bunch of async stuff
        return cmdline.complete; } finally { __efc(this, 'cmd'); } <-- __efc / getContext() may or may not get right value.

Such a headache!

Offline silenus

  • BFF
  • ***
  • Posts: 193
    • View Profile
Re: new driver development.
« Reply #22 on: January 28, 2018, 06:07:27 PM »
Well I am not saying that a noninstrumentation approach does not work but I think instrumentation is quite general and can cope with a multitude of problems if used correctly. The perhaps canonical method for doing this is to find all loop backedges and do some sort of check on each one (perhaps have a counter) and do the same for every function entry. What is __bfc() and __efc()?

Offline kriton

  • Acquaintance
  • *
  • Posts: 23
  • ICQ??! AIM?! Just how old is this place?
    • View Profile
Re: new driver development.
« Reply #23 on: January 29, 2018, 07:15:14 PM »
Well I am not saying that a noninstrumentation approach does not work but I think instrumentation is quite general and can cope with a multitude of problems if used correctly. The perhaps canonical method for doing this is to find all loop backedges and do some sort of check on each one (perhaps have a counter) and do the same for every function entry. What is __bfc() and __efc()?

__bfc/__efc (begin/end function call).  I am asserting alarm time and maintaining an object stack (for this_object / previous_object functionality and for valid_* applies).  The loop assertion does have a counter so it's not doing a full assertion on every pass through the block.

I ended up passing a handle through the block with another user-restricted identifier (__ctx) :P

I am also thinking about adding protected/private modifiers for properties and methods to be more like other languages.

Code: [Select]
    setRouterList(data) {
        let __ctx = __bfc(this, 'setRouterList'); try { var routers = { length: 0 };
        Object.keys(data).forEach(function (id) {
            let __ctx = __bfc(this, 'undefined'); try { if (id.startsWith('*')) {
                routers[id] = new I3Router(data[id]);
                routers.length++;
            } } finally { __efc(__ctx); }
        });
        this.setProtected('routerList', routers); } finally { __efc(__ctx); }
    }

Offline silenus

  • BFF
  • ***
  • Posts: 193
    • View Profile
Re: new driver development.
« Reply #24 on: January 30, 2018, 09:34:20 PM »
I think obviously you have function call checking already probably not too hard to add that if you want. I am currently working on hacking garbage collection (something that js has built in) into fluffos. Quite a bit of spadework involved. Mostly involving tracking down where candidates for the root set are. I am almost done though. I will see if I can get the whole thing finished by the end of the week. After that I will probably try to assess how much work it is to use LLVM as a JIT for fluffos. Probably try to just do some sort of call threading for now and make it very minimal.

Offline silenus

  • BFF
  • ***
  • Posts: 193
    • View Profile
Re: new driver development.
« Reply #25 on: April 12, 2018, 10:44:58 AM »
I have been doing some other things for a little while but I would like to get back to learning some programming. Is anyone here familiar with Rust? My understanding is that it's a systems programming language like C/C++ but perhaps a bit easier to learn and with a cleaner syntax. I am wondering how much work it would be to write a parser in it for a version of lpc by essentially translating some of the fluffos code in the compiler in vm into it.