As part of Resurgence's goals, a C API is planned to allow the VM to load C libraries. This will require a few things:

1. An API design. Personally, I think we could make an API similar to Lua's C API.
2. A way to load a module. This needs to be done in a way that also allows easy access to the functions loaded in the Resurgence Embedding API.
3. A way to call functions from the module. This should not be too slow, but it should also be simple to understand.

I'll be assigning this to @dynafide. The c_api branch has already been created for this task

The idea is to decouple RunTimeSeal from the interpreter and replace it with Cardinal. Cardinal wraps around the interpreter process and acts like a simple kernel, handling extension calls and all that

Pros:

• Easier to secure
• Simpler to understand then RunTimeSeal
• Implementing things like permissions is a piece of cake and doesn't require much refactoring of the interpreter Cons:
• Massive refactoring needed
• Removal of some bytecode instructions
• ExtCall needs to be replaced with some sort of system instruction

We need to finish implementing the codegen (Code Generation) API for compilers to use to simplify the process of generating bytecode. This will help eliminate the need to rewrite the code generator and manually outputting the byte code format byte-for-byte. This will also help simplify the effort to rewrite our RASM assembler program in Rust.

A reader and writer mechanism will be needed for storing and transmitting byte code. I'm currently working on this, so I'm assigning myself to the issue.

This pull request adds the planned imports table into the bytecode reader and writer code as part of issue #5. I am unable to fully test this change right now, but everything should work.

Add a crash / core dumps mechanism that can either be triggered manually or when faults occur. This will help with debugging both the Resurgence VM as well as programs running inside of it. Core dumps should contain the following:

• a copy of the instructions and bytecode header re-encoded from the Codeholder
• a list of the states of each recursive execute_instruction call, including the register values and the current instruction number they are at
• a complete copy of all stack frames
• a complete copy of the stack

This should be output in a portable binary format that can be used in other applications for debugging purposes.

It may be a good idea to add seccomp support to Resurgence to further enforce secure computing. I see two ways we could implement this feature:

The first way we could implement it would look something like this:

• When the interpreter instance is created, it also creates a new seccomp thread that listens on an internal IPC interface, such as shared memory or a FIFO pipe
• Whenever any future calls are made to the interpreter, they are forwarded to the seccomp thread over the IPC interface
• When the interpreter instance is destroyed, it ends the seccomp thread

This way, the seccomp functionality is completely internal to Resurgence and is abstracted away from the host application entirely.

We could also implement it the second way, which would look something like this:

• Resurgence provides some sort of seccomp_enable and seccomp_disable functions in the API
• The host application directly sets up and tears down the seccomp thread and runs the entire Resurgence VM inside of it

This would be more secure, but would make it much more difficult to use for developers of host applications.

This checklist is the stuff left for the first alpha release of Resurgence:

• [ ] #8
• [ ] #9
• [x] #15
• [ ] Finish C FFI (including returning errors instead of just status)
• [x] Make sure @dynafide adds himself to Cargo.toml
• [x] Add drop to stack methods for the Rust and C APIs ~~- [x] Make sure RunTimeSeal can catch most if not all attempts of tampering the runtime (this will definitely not be finished by the first alpha, but we can try our best)~~ EDIT: RunTimeSeal will be removed as it doesn't bring much benefit
• [ ] Publish on Crates.io
• [x] Update diagrams in README
• [ ] Port RASM to Rust (requires code gen API to be finished)
• [x] Make sure that RASM can compile all instructions
• [x] BIG ONE: add Global support for FrameAlloc and FrameFree
• [x] Make sure function visibility is correct (internals should not be usable to the end user)

@dynafide anything else we need to check off before we release alpha 0.2.0?

To improve the descriptiveness of runtime errors and faults, we should modify the error handling in some way which allows the calling application to trace the call stack and determine the instruction that triggered a fault. Some information about the state of registers and the stack (similar to a core dump) would also be useful.

This will help users debug RVM code as well as enable us to find flaws in the VM itself.

In order to improve the stability of Resurgence as a library, all calls to panic!() .unwrap() and todo!() should be rewritten to pass results to the calling application. I'm creating this issue to keep track of progress.